3 ms·

Plus <title> tag is valid in SVG context, where it does what `title` attribute does on HTML elements (provides content for HTML tooltips and screen readers). A

by myfonj 4y ago

Plus <title> tag is valid in SVG context, where it does what `title` attribute does on HTML elements (provides content for HTML tooltips and screen readers). And since inline SVG is valid in HTML, you can get valid title tags (from SVG namespace) outside HEAD element Plus if there wasn't TITLE in the head and is encountered inside BODY (not valid), it is adopted into the HEAD from document object model's perspective as if it was hoisted there (but it is not, just its value): data:text/html;charset=utf-8,<head>  </head> <body bgcolor=dimgray> <svg viewbox="0 -15 80 20" fill=cyan> <title>SVG Tooltip</title> <text>Some SVG<text> </svg> <title>Title For Adoption.</title> <title>Second late title.</title> <p>And the title is: »<output id=o></output>«. <body onload="o.value = document.title"> <body text=snow> Resulting paragraph reads: "And the title is: »Title For Adoption.«." ("Yet unseen attributes" of the consecutive BODY tags are physically "hoisted" to real body node, but it's a different chapter.) Plus both <head> / </head> tags are optional — and implied — so "selecting title in head tag" can become very hard task, if taken seriously. Making HTML parser ain't easy.

chrismorgan 4y ago
You complicate the description and make it sound much harder than it actually is. Concerning HTML parsing in general: it is easy, genuinely easy, one of the easier things to implement, because it’s well-defined, and in a format that matches the implementation. You’re basically just translating the algorithm from pseudocode into code. Sure, it’s long, but it’s not hard. <head> and </head> being optional is purely a parser concern, that the start and end tags are optional. Implement the parser, and you get that behaviour automatically, and nothing beyond that needs to worry about it at all. For that matter, you don’t need to worry about head or body in determining the title, because here’s how the document title is actually determined, per https://html.spec.whatwg.org/multipage/dom.html#the-title-element-2 https://html.spec.whatwg.org/multipage/dom.html#the-title-el...: > The title element of a document is the first title element in the document (in tree order), if there is one, or null otherwise. (And then it goes on to describe further processing done for the document.title attribute.) The only subtlety in this explanation is that when it speaks of title elements, it’s speaking of HTML title elements only. There’s nothing complicated or difficult about this. There’s no adoption, it’s just taking the first HTML title anywhere in the document. (If implementing this in browser JavaScript, you can’t just use document.querySelector("title") because it ignores namespaces. The most efficient way will be to use document.evaluate() with an XPath like "//title/text()" which matches the required child text content nodes.)
- 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

You complicate the description and make it sound much harder than it actually is. Concerning HTML parsing in general: it is easy, genuinely easy, one of the easier things to implement, because it’s well-defined, and in a format that matches the implementation. You’re basically just translating the algorithm from pseudocode into code. Sure, it’s long, but it’s not hard. <head> and </head> being optional is purely a parser concern, that the start and end tags are optional. Implement the parser, and you get that behaviour automatically, and nothing beyond that needs to worry about it at all. For that matter, you don’t need to worry about head or body in determining the title, because here’s how the document title is actually determined, per https://html.spec.whatwg.org/multipage/dom.html#the-title-element-2 https://html.spec.whatwg.org/multipage/dom.html#the-title-el...: > The title element of a document is the first title element in the document (in tree order), if there is one, or null otherwise. (And then it goes on to describe further processing done for the document.title attribute.) The only subtlety in this explanation is that when it speaks of title elements, it’s speaking of HTML title elements only. There’s nothing complicated or difficult about this. There’s no adoption, it’s just taking the first HTML title anywhere in the document. (If implementing this in browser JavaScript, you can’t just use document.querySelector("title") because it ignores namespaces. The most efficient way will be to use document.evaluate() with an XPath like "//title/text()" which matches the required child text content nodes.)

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>