Live data from Hacker News

Solving the regex of madness, and snarky answers on StackOverflow (2019)

cargocultcode.com

41–50 of 136 posts

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#41
post #5

Try that regex on console.log(" "); Edit 1: I'm unsure if the inner is valid (X)HTML, so it might not be an issue of being unable to parse correct (X)HTML, but rather an issue of being unable to detect invalid (X)HTML. (Can someone verify?) Edit 2: It seems Chrome chokes on the space... does anyone know if the initial space is valid? I'm pretty sure I've seen parsers that accept it...

> Edit 2: It seems Chrome chokes on the space... does anyone know if the initial space is valid? I'm pretty sure I've seen parsers that accept it...

Most browsers probably can deal with it, but it's not valid xml/html. Try passing it through a validator, it'll complain about foreign characters after `` as was never opened in the first place.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#42

Long regexes are the root of all evil

Long regex's are not the root of all evil but they're certainly a tendril of bad-practice. I would say that the OP's usage, a home-made concoction to find all opening tags in an xhtml doc, crosses the line into bad practice. Get a room and use a parser, people!

So if using regular expressions is "bad practice", how should one write the tokenizer or lexer stage of a parser?

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#43

It's not explicitly stated, but I believe the author's point is that the original question didn't require a recursive solution (because it's only asking about individual tags, not matching opening tags with their closing partners) Edit: yes looking at the answers, someone pointed this out in a comment response to the"Chomsky" answer: > The OP is asking to parse a very limited subset of XHTML: start tags. What makes (…

Look again. The context is definitely one of identifying tags that should be closed, but aren’t, and being identified thus in order to normalise a malformed document into well-formed XHTML. It is not prominently stated, but it is nevertheless the case. Consequently, balance matters. The clue is in the title: “match open tags”, for which the body text has only one part of the author’s train of thought (i.e identifying the opening tag). Further discussion of matching the closing tag is omitted from the body of the question, and many people forget (or disregard) the nuanced difference in the title at this point in their read-through, not stopping to ponder “why the heck would they just want the opening tags? what have I missed here about the context?” and instead treating it like some particularly awful and weirdly contrived exam question, as in the article at the top.

The final confirmation of all this is in the question history of the question author around the same date: it’s definitely what they were working on.

Consequently, our zalgo-spewing correspondent has it right, they should use a parser, and in addition the question should’ve received feedback early to help them describe the context more clearly.

That all this was never properly clarified is a failure of moderation, and further a demonstration of how many folks struggle to challenge (or even identify) their own assumptions.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#44
The problem is: you cannot parse malformed (real, everyday) html with regexes.

But if you need to parse html even malformed) generated by the same template (like a scrapping situation), the whole file becomes regular, which can be parsed by a regular expression.

But if you try to parse html in general, too bad because then you’ll need to take html in consideration and will need a recursive descent parser, not a regex.

This question popped up so many times in forums in 2000’s that people got mad at that.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#45

It's not explicitly stated, but I believe the author's point is that the original question didn't require a recursive solution (because it's only asking about individual tags, not matching opening tags with their closing partners) Edit: yes looking at the answers, someone pointed this out in a comment response to the"Chomsky" answer: > The OP is asking to parse a very limited subset of XHTML: start tags. What makes (…

Look again. The context is definitely one of identifying tags that should be closed, but aren’t, and being identified thus in order to normalise a malformed document into well-formed XHTML. It is not prominently stated, but it is nevertheless the case. Consequently, balance matters. The clue is in the title: “match open tags”, for which the body text has only one part of the author’s train of thought (i.e identifying…

"Match open tags" obviously refers to writing a regular expression which matches opening tags, not to pair opening tags with end tags.

If you look at the regex which the OP themself suggests, it is clearly only intended to match opening tags (excluding self-closing tags), not search for corresponding end-tags.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#46
post #45

Earlier quoted context omitted.

Look again. The context is definitely one of identifying tags that should be closed, but aren’t, and being identified thus in order to normalise a malformed document into well-formed XHTML. It is not prominently stated, but it is nevertheless the case. Consequently, balance matters. The clue is in the title: “match open tags”, for which the body text has only one part of the author’s train of thought (i.e identifying…

"Match open tags" obviously refers to writing a regular expression which matches opening tags, not to pair opening tags with end tags. If you look at the regex which the OP themself suggests, it is clearly only intended to match opening tags (excluding self-closing tags), not search for corresponding end-tags.

Well, as now expressed at hopefully sufficient length, it doesn’t just say solely that, unless one a) disregards the difference in phrasing, and then b) disengages any sense of purpose and practical utility and instead treats it like a badly worded test question.

It’s kind of a shibboleth, in a way, for developer sensitivity to actual needs, as opposed to getting hung up on how clever they are.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#47

I love seeing the weirdo CDATA thingy in there! CDATA ftw! E.g., you've got this enormous spec for SVG which includes CSS, but that CSS has syntax inside a style tag which could break XHTML parsers. Amateurs out there are probably thinking, "Well, why not just compromise in the spec and tell implementers to do the same thing that HTML does to parse style tags?" Well, professionals know that cannot work for myriad rea…

>My holy grail-- how do I use DOM methods to create a CDATA element to shove my style into? If I could know this then I can jump my Dodge Charger back and forth into XHTML without ever getting caught.

Does this help? https://developer.mozilla.org/en-US/docs/Web/API/Document/cr...

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#48

> The question is about finding opening tags in XHTML using a regular expression Bzzzt, wrong, sorry! The question is about finding open tags in the presence of XHTML self-closing tags. That difference alone places these interpretations gulfs apart. But there’s more: it does not specify that the input document is even XHTML, only that XHTML-style self-closing elements may be present. In fact the original question was…

Here's the original text for reference:

    Locked. Comments on this question have been    disabled, but it is still accepting new answers and    other interactions. Learn more.
    
    I need to match all of these opening tags:
    
    

But not these: I came up with this and wanted to make sure I've got it right. I am only capturing the a-z. I believe it says: Find a less-than, then Find (and capture) a-z one or more times, then Find zero or more spaces, then Find any character zero or more times, greedy, except /, then Find a greater-than Do I have that right? And more importantly, what do you think? html regex xhtml Share Improve this question edited May 26 '12 at 20:37 community wiki 11 revs, 7 users 58% Jeff

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#49

Earlier quoted context omitted.

Regular expressions in the formal language theory do not have captures anyway. The name collision is unfortunate, but we have already established that regexes in practice means a pattern language largely modelled after theoretical regular expressions and not the theoretical regular expressions themselves. At the very least the writing could have mentioned this discrepancy.

>At the very least the writing could have mentioned this discrepancy. The original meaning of 'regular expression' is very specific, and has some significant implications which are lost with the now-common and less well-defined usage. Therefore, if anything needed having this discrepancy mentioned, it was your original statement "it is patently false that regular expressions cannot be recursive", as this is an issue…

I intentionally used the term "regex" elsewhere for that reason, but I later realized that the indirect quotation can be still problematic.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#50
post #48

> The question is about finding opening tags in XHTML using a regular expression Bzzzt, wrong, sorry! The question is about finding open tags in the presence of XHTML self-closing tags. That difference alone places these interpretations gulfs apart. But there’s more: it does not specify that the input document is even XHTML, only that XHTML-style self-closing elements may be present. In fact the original question was…

Here's the original text for reference: Locked. Comments on this question have been disabled, but it is still accepting new answers and other interactions. Learn more. I need to match all of these opening tags: But not these: I came up with this and wanted to make sure I've got it right. I am only capturing the a-z. I believe it says: Find a less-than, then Find (and capture) a-z one or more times, then Find zero or…

Not sure which revision that's pasted from, but it is not the original text, which can be found at https://stackoverflow.com/revisions/1732348/1 and I strongly advise against neglecting the title; doing so is how some folks blunder into misinterpretation, since the wording of that title is telegraphing a quite different underlying need to "please solve this regex puzzle".
Post reply on HN