3 ms·

I'm not sure if I follow your line of thoughts correctly. I agree that yes, HTML parsing is well defined in current standard, but (subjectively, for me) it is

by myfonj 4y ago

I'm not sure if I follow your line of thoughts correctly. I agree that yes, HTML parsing is well defined in current standard, but (subjectively, for me) it is far from "easy", given the amount of states and back-compat "burden" with plenty of often overlooked exceptions. (I like to explore them but I'd never try to make a compliant HTML parser from scratch, probably.) I was in fact responding to > […] I've learned, from building a [HTML] parser […] you need to select the title tag in the <head>-tag. what gave me impression OP really rolls his own HTML parser and relies on some possibly dangerous assumptions that are not in fact granted (however well defined) by the specs — for me one of such assumption is especially "HTML parsing is easy" / "I understand HTML well enough to parse it myself" — and wanted to point out possible further gotchas wrt "selecting the <head>-tag" (e.g. that it may be hard when there is no <head> tags) or that "selecting the first title tag" could possibly not give the right one. But maybe I'm just little slow and all those "Idiosyncrasies of the HTML parser" [1] are notoriously known. And sure, many scenarios could be waved out as unimportant border-cases, maybe. --- As for querying the document, i.e. having the state when the document is ready and "something" did the parsing and tree heavy lifting for us (so we have DOM and JS) we can surely reach for ancient namespaced document.getElementsByTagNameNS("http://www.w3.org/1999/xhtml", "title")[0]?.textContent?.trim() (hopefully there are no further details wrt comments, white-space normalization and entity expansion on top of raw textContent we should take care of) but it makes very little sense when there is `document.title` for this exact purpose. --- [1] https://htmlparser.info/parser/ https://htmlparser.info/parser/

chrismorgan 4y ago
To implement an HTML parser, you don’t need to worry about the corner cases at all, because the spec has your back and spells out exactly how every single case should be handled, in the form of state machines, which is how you will implement it. There are involved details, to be sure, but it’s genuinely not hard to follow the spec. The idiosyncrasies document you cite is for authors of HTML: implementers genuinely don’t need to worry about them, because it’s all covered by the spec. For document.title: naturally in a browser you would use that; I intended to describe just how you would achieve it without that. And I completely forgot about document.getElementsByTagNameNS for some reason, which is of course more sensible than a querySelector + find. Note that .textContent.trim() doesn’t match the algorithm which is spelled out in the spec (just below the earlier link), on two counts. Firstly, all sequences of ASCII whitespace in the middle of the string need to be collapsed to a single space ("\r\n\f\t hello\r\n\f\t world\r\n\f\t " → "hello world"). Secondly, .textContent is insufficient, including the text content of element children as well, whereas the spec says child text content (with a link to the exact definition); HTML syntax can’t produce such elements (the parser switches into RCDATA state), but XML syntax can, as can DOM manipulation by scripting. Examples that are both titled “included” rather than the textContent “inclexcludeduded”: data:application/xhtml+xml,<title xmlns="http://www.w3.org/1999/xhtml">incl<b>excluded</b>uded</title> data:text/html,<title>incl</title><script>document.querySelector("title").append(b=document.createElement("b"),"uded"),b.append("excluded")</script>

by myfonj 4y ago

chrismorgan 4y ago

To implement an HTML parser, you don’t need to worry about the corner cases at all, because the spec has your back and spells out exactly how every single case should be handled, in the form of state machines, which is how you will implement it. There are involved details, to be sure, but it’s genuinely not hard to follow the spec. The idiosyncrasies document you cite is for authors of HTML: implementers genuinely don’t need to worry about them, because it’s all covered by the spec. For document.title: naturally in a browser you would use that; I intended to describe just how you would achieve it without that. And I completely forgot about document.getElementsByTagNameNS for some reason, which is of course more sensible than a querySelector + find. Note that .textContent.trim() doesn’t match the algorithm which is spelled out in the spec (just below the earlier link), on two counts. Firstly, all sequences of ASCII whitespace in the middle of the string need to be collapsed to a single space ("\r\n\f\t hello\r\n\f\t world\r\n\f\t " → "hello world"). Secondly, .textContent is insufficient, including the text content of element children as well, whereas the spec says child text content (with a link to the exact definition); HTML syntax can’t produce such elements (the parser switches into RCDATA state), but XML syntax can, as can DOM manipulation by scripting. Examples that are both titled “included” rather than the textContent “inclexcludeduded”: data:application/xhtml+xml,<title xmlns="http://www.w3.org/1999/xhtml">incl<b>excluded</b>uded</title> data:text/html,<title>incl</title><script>document.querySelector("title").append(b=document.createElement("b"),"uded"),b.append("excluded")</script>