> 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…
Solving the regex of madness, and snarky answers on StackOverflow (2019)
51–60 of 136 posts
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#52Earlier quoted context omitted.
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)
#53Earlier quoted context omitted.
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.
Still, I'm just making a comment about the overhead... I would hedge a guess that you're going to have a hard time beating a regex with an HTML parser for speed, assuming what you want can be done with both.
This is all irrelevant, because as the OP mentions, the SO question at hand cannot be solved with standards compliant parsers because self-closing tags will not be distinguishable.
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#54Earlier quoted context omitted.
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)
#55This 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.
... and then there's the anticipated joy of seeing the pedants' complicated, theoretically correct solution explode because the input wasn't what they assumed, in the first place.
The pedants that have that experience either become enlightened, or vociferously strident about the importance of proper, theoretically correct solutions in place of quick hacks.
Thus the meme status of the SO answer.
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#56Earlier quoted context omitted.
"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.
Who are you to know the purpose and utility better than the person who asked the question ?
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#57just because you can doesn't mean you should
just take a look at proposed regex
>(
> # match all tags in XHTML but capture only opening tags
> ? --> # comment
> | ? \]\]> # CData section
> | /'""] )* >
> | ? \?> # xml declaration or processing instruction
> | "" | ' [^']* ' | [^>/'""] )* /> # self-closing tag
> | \w+ ) ( "" [^""]* "" | ' [^']* ' | [^>/'""] )* > # opening tag - captured
> | # end tag
> )
it's ugly as hell
>Parsing typically uses (at least) two steps: Tokenization which uses regular expressions to splits the input string into a sequence of syntax elements
I don't use regex for tokenization, I'm doing something wrong?
But overall I think this is important post, even despite I believe that regex is the best example of "good idea, shitty API"
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#58Earlier quoted context omitted.
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.
> disengages any sense of purpose and practical utility and instead treats it like a badly worded test question. Who are you to know the purpose and utility better than the person who asked the question ?
Alternatively, perhap, that hostile tone is suggesting I’m personally unqualified to interpret loosely framed questions? I suppose, since I’ve only been doing it for a few decades, I’m definitely a novice by any standard, and my tendency to observe and follow up on anomalous, incomplete, subtly conflicting, or otherwise inexplicable requirements by investigating both the timeline and substance of the original context, and the apparent motivations and outcome preferences of the author, is sheer beginners luck, and any uptick in stakeholder utility that from time to time accompanies amending recommendations following such investigative and analytical activity a sheer coincidence! So that must be it - as you can probably tell from all this smug, empty bravado, I’m really just sharing pure speculation, wild guesswork, total fluke, impertinent leaps of inferential faith, only just grasping at the vague outline of my own blind spots et cetera et cetera, and consequently yes, I’d love to hear the original intent restated from the horse’s mouth, too; but, for the meantime, I’ll read the tealeaves, systematically analyse and synthesise to the best of my ability, describe and discuss any substantive points of comprehension that I think might help enrich, or at any rate challenge, a reader’s perspective (including my own), and cross my fingers hoping to read, mark, and inwardly digest what new understanding or revealed wisdom as I can - even when it comes, as it has there and here, via diacritical allegory and dialectical hellfire.
Or, finally, if you just want the TL;DR version, the reason I feel unshakeably comfortable asserting that the question author's actual purpose is normalising a nonconforming document into XHTML, by balancing open & close tags, is because they said so.
It's in an answer comment about halfway down the first page.
> "Can you provide a little more information on the problem you're trying to solve"
"Determining all the tags that are currently open, then compare that against the closed tags in a separate array"
If that's not enough, here are quotes from their other questions, posted in the minutes and hours prior:
"How to balance tags with PHP", and
"I need to write a function which closes the opened HTML tags."
Sometimes, we just have to bother reading what's in front of us.
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#59put arbitrary html here as you please (using single quotes for attributes)
Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)
#60Does the proposed regular expression really handle embedded script content correctly? From my limited understanding of HTML, pretty much only counts as closing the script contents and everything else is treated as part of the script.
Does it matter? You can create regex with lookahead for . The point is that it's possible to solve the problem from SO this way, due to the nature of the problem, not that this particular expression is perfectly correct.