Re:Summoning Cthulhu by Parsing HTML with Regular Expression...
by chrismorgan on Saturday April 16, 2022 @05:17AM
(#31050914)
As regards HTML, this article is terrible and completely wrong and demonstrates just why you shouldn’t try parsing HTML with regular expressions.
> <p>Hello World!</p> is valid HTML. <p><p>Hello World!</p></p> is also valid HTML. On the other hand, <p><p>Hello World!</p> is not valid HTML
The first one is correct: <p>Hello World!</p> is indeed valid HTML.
But <p><p>Hello World!</p></p> is not valid HTML (though, like everything, it has a well-defined parse), and probably never was (though I’d need to check to be sure; and I do know that unmatched </p> used to be moderately popular, as it often achieved close to the same result as having the opening tag).
And <p><p>Hello World!</p> is valid HTML, and always has been.
It sounds like the writer is trying to parse a very limited or idealised subset of XML or XHTML, not HTML.
> HTML is a CFG*
> *Caveat: this should be true at least in theory, given HTML's tree structure. However, in practice, many browsers will be able to parse "invalid" HTML (for example, you can forget to add a closing tag, and in most cases the browser will be perfectly fine with that). Even worse, browsers don't all agree on what valid HTML actually is. Since this blog post is about regexes, and not about HTML, I decided to leave out any discussion about how to actually define HTML.
That footnote at the end is the nail in the coffin that confirms that the author is just completely clueless about HTML as it exists now, and probably its historical state too. HTML parsing is exhaustively defined, with all browsers having used the same parsing algorithm for a decade or so. (I will admit that there have been a few minor changes in that algorithm over time; <template> is probably the most significant, though in practice that’s kinda more about interpretation than parsing.) This is not something that can be said of many languages. In practice even XML isn’t as well defined or consistent as HTML (will DTD entities work? External ones? &c.).
“Valid” is basically just a rubber stamp in HTML—that certain places in the state machine can report a parse error, but that nothing will actually come of it. There’s no intrinsic reason to care about validity: HTML that is labelled invalid will work just as well as valid HTML¹. The only reason to think about it is that it suggests you may have made a mistake.
> <p>Hello World!</p> is valid HTML. <p><p>Hello World!</p></p> is also valid HTML. On the other hand, <p><p>Hello World!</p> is not valid HTML
The first one is correct: <p>Hello World!</p> is indeed valid HTML.
But <p><p>Hello World!</p></p> is not valid HTML (though, like everything, it has a well-defined parse), and probably never was (though I’d need to check to be sure; and I do know that unmatched </p> used to be moderately popular, as it often achieved close to the same result as having the opening tag).
And <p><p>Hello World!</p> is valid HTML, and always has been.
It sounds like the writer is trying to parse a very limited or idealised subset of XML or XHTML, not HTML.
> HTML is a CFG*
> *Caveat: this should be true at least in theory, given HTML's tree structure. However, in practice, many browsers will be able to parse "invalid" HTML (for example, you can forget to add a closing tag, and in most cases the browser will be perfectly fine with that). Even worse, browsers don't all agree on what valid HTML actually is. Since this blog post is about regexes, and not about HTML, I decided to leave out any discussion about how to actually define HTML.
That footnote at the end is the nail in the coffin that confirms that the author is just completely clueless about HTML as it exists now, and probably its historical state too. HTML parsing is exhaustively defined, with all browsers having used the same parsing algorithm for a decade or so. (I will admit that there have been a few minor changes in that algorithm over time; <template> is probably the most significant, though in practice that’s kinda more about interpretation than parsing.) This is not something that can be said of many languages. In practice even XML isn’t as well defined or consistent as HTML (will DTD entities work? External ones? &c.).
“Valid” is basically just a rubber stamp in HTML—that certain places in the state machine can report a parse error, but that nothing will actually come of it. There’s no intrinsic reason to care about validity: HTML that is labelled invalid will work just as well as valid HTML¹. The only reason to think about it is that it suggests you may have made a mistake.
¹ Not necessarily true per https://html.spec.whatwg.org/multipage/parsing.html#parse-er...: user agents are allowed to abort on the first parse error; but in practice I’ve never heard of any implementation doing so.