Scraping recipes from the bbc, flight reservations from my email, etc. If something includes schema.org/RsvpAction it probably needs to be actioned, if something contains schema.org/DiscountOffer it can probably go in the Noise folder.
If someone starts sending spam containing flight reservation meta I'm going to be so sorely disappointed in the human race.
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>
<!-- <title>not here</title> -->
</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>
("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.
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-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.)
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()
---
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>10-15 years ago, we had a bunch of different ways everyone was trying to schematize their data on the web, and since we never all agreed to just use one of them, everyone now uses fragments of all of them — and of other pseudo-proprietary systems — in their own unique ways.
How would this help alleviate those problems?
[1] To this day. I've learned, from building a parser for my search engine, you can't just select the <title> tag if you want the title of a page. You need to select the title tag in the <head>-tag. Otherwise you'll get the title-tags people semi-regularly use in the body as well... Like not just hobbyists. Found a major American university that used title-tags to wrap navigational links.