1. determine size of XHTML input
2. build regex that works up to the size determined in step 1.
3. apply regex
Solving the regex of madness, and snarky answers on StackOverflow (2019)
31–40 of 136 posts
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#32Long regexes are the root of all evil
If the task at hand is something which can be solved with a regex, then any other solution (e.g manual string scanning) would be far more complex.
I am guilty of this type of thinking as well. I saw the errors of my ways when I had to fix someone’s else regular expressions
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#33The author seems to be missing the point, in my opinion. While it is certainly true that often one can solve simple, seemingly innocent sub-problems within more general languages, the transitions from "I see I can solve this simple program with regex'es!" to "Then I can probably solve this other, almost identical problem as well!" and have the problem explode right into your face are subtle (almost imperceivable to a…
The regex is surely faster for the specific case. I can't say I've seen an XHTML parser off hand that allows me to stop parsing after just the start tag. Perhaps a lazy parser could start to compete, but I'm just guessing.
Aren't most XML parsers SAX or STaX based? Only time I ran into a library that only offered a full DOM without the underlying event based parser was whatever browsers consider the JavaScript standard library.
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#34I 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 reasons you can read about if you take out a college loan and remain sedentary for the required duration.
The right approach is to throw the CSS stuff inside CDATA tags to tell the parser not to parse it so things don't break. That is the way sensible, educated professionals solve this problem.
I'm only kidding!
For inline SVGs the HTML5 parser simply says, "Parse this gunk as HTML5, and use sane defaults to interpret the parsed junk in the correct svg namespace so that all the child thingies in that namespace just work."
Which it does.
Unless you're going to grab the innerHTML of the inline SVG and shove it into a file to be used later as an SVG image.
In that case you cross the invisible county line into XHTML territory where the sheriff is waiting to throw you in jail for violating the CDATA rule. In that case the XHTML parser hidden in the guts of the browser doles out the justice of an error in place of your image. Because that is the way sensible, educated professionals solve this problem. :)
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.
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#35Long 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!
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#36The author seems to be missing the point, in my opinion. While it is certainly true that often one can solve simple, seemingly innocent sub-problems within more general languages, the transitions from "I see I can solve this simple program with regex'es!" to "Then I can probably solve this other, almost identical problem as well!" and have the problem explode right into your face are subtle (almost imperceivable to a…
The article goes as far as to say that a parser is not the right tool.
> Not only can the task be solved with a regular expression - regular expressions are basically the only practical way to solve the problem. Which is why none of the clever answers actually suggest another way to solve the problem.
So no, the author is not missing the point at all.
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#37Earlier quoted context omitted.
Captures are a red herring here. They don't fundamentally alter the nature of what a regex does, which is to recognize regular languages. Pointing to them as if they're some kind of justification is like calling pilots "drivers" because drivers originally drove wagons, and wagons didn't have rubber tires like cars and planes anyway. It's completely missing that the point of the distinction between a plane and a wagon…
> They don't fundamentally alter the nature of what a regex does, which is to recognize regular languages. It's a bit subjective but captures are harder than recognition. Russ Cox has once noted [1] that the extraction has to be run as a separate step after the recognition and a fast DFA can't always be used for that, suggesting they are related but different problems. [1] https://swtch.com/~rsc/regexp/regexp3.html
Well, if you allow an arbitrary depth of capture-group nesting, then that may be so, but it seems beside the point here. It is not clear to me that this article makes any point about extraction that is relevant to this discussion.
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#38Weird article that basically says people are wrong then prove they are right.
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#39> 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 barely minutes old and tagged merely “regex” when that famous answer was written in 2009; the question was not tagged with “xhtml” until 2012, and not by the original author either.
Revealingly, then, if we review the broader context (i.e question history) of the original question author, it’s clear that yes indeed they were trying to fix a malformed document, and in particular to normalise it into XHTML, with focus on fixing up any so-called “dangling tags”. For this task, the suggestion of “use a parser” is indeed sound advice.
The real moral here is, don’t be a jerk about the precise semantics of a question, look at what the person needs, and help them ask better questions.
Otherwise, you’re just gonna discover that there’s always a bigger jerk, and they’re on Stack Overflow, moderating your stuff.
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#40This is one of those things that people will debate about endlessly and ultimately it feels so silly.
The poster asked how to do it, and this person provided a practical regex to cover most (if not all) cases.
Everything else is just pedantic debate.