Hacker News Reader

Comment by tedmiston | Hacker News Reader

Just to put the code sample here...

    <!-- Not recommended -->
    <!DOCTYPE html>
    <html>
      <head>
        <title>Spending money, spending bytes</title>
      </head>
      <body>
        <p>Sic.</p>
      </body>
    </html>

    <!-- Recommended -->
    <!DOCTYPE html>
    <title>Saving money, saving bytes</title>
    <p>Qed.

Does the <head> tag really not matter anymore?

View on HN

I never really thought about it much, but there's no reason it needs to.

There is not really any ambiguity that the head tag solves ever. Script tags don't act differently in or out of the head tag, and things like <title> are always going to do the same thing, so having the <head> block is at best a "comment" to the user that these elements are "head related".

One difference: when a script executes in the <head>, the <body> doesn't exist yet — document.body is null.

A <script src="…" defer> always runs with a body, which is nice in any case since it keeps scripts together, lets the browser start loading every script right away, and is explicit about which ones need to run before the body. Sadly, defer is only allowed for script elements with a src attribute.

I've been sleeping on best practices here... is it preferred to do a script with defer in the <head> over putting it at the bottom of the <body> now?

Doesn't matter much with defer or async. If you but the at the bottom, they start loading in parallel slightly later.

Which could be a good thing or bad thing depending on its importance to the experience.

I'd say yes. Defer-in-<head> works just like bottom-of-<body>, except the browser can start downloading and parsing the scripts right away (and in parallel if it wants).

That's just because of ordering, though. Test it:

    <html>
      <body></body>
      <head><script>alert(document.body);</script></head>
    </html>

works fine. It's not a head vs. body distinction, it's just that the parser is stopped during inline scripts, and doing e.g. getElementById won't work if the script is declared after you.

This is why window.onload and then jQuery's document.ready, and later, putting the script at the end of your file, is a best practice.

What's happening isn't what you think is happening.

The parser creates an empty head element when it sees the <body> start tag, the second <head> start tag is ignored, and the <script> is treated as part of the body element. Try changing the body of the <script> tag to this:

    alert(document.currentScript.parentNode);

It alerts "[object HTMLBodyElement]".

The behavior is specced out here, if you're curious: https://www.w3.org/TR/html5/syntax.html#parsing-main-afterbo...

Put the meta stuff in the header, like styling, alternate languages and stuff that are not content. Things that conserns the compiler.

<head> does matter and you have to write your HTML as if it were there, so you can't place <title> after anything that would belong in the <body>.

Think of <HTML>, <head> and <body> as implied rather than missing.

Yeah, essentially the _tag_ is optional, but the element is still there.

An example of a tag that almost everyone omits is <tbody>. A <tr> can't exist directly under <table> (per the DTD), so you're explicitly opening a <tbody> with your first <tr> and closing it with your </table>. If you look at the DOM in the browser, the <tbody> will be there.

What's the tbody for? Can I write a table with multiple tbody's? What would be the effect?

tbody is the table body, the DTD allows multiple tbodys and says "Use multiple TBODY sections when rules are needed between groups of table rows". (By "rules" they mean solid horizontal lines, but I think you'd have to explicitly add any horizontal rules that you want via CSS)

Typically, you have one table header (thead) and one table body. In print, if the table spans multiple pages, you would want the header to re-appear on each page.

head's start and end tags have been optional for almost forever. You could omit both per the HTML 2.0 DTD, the first standard version of HTML. (Some of the earlier drafts didn't allow them omitted, though.)

I'd have to test this, but I'm pretty certain screen readers will not know how to properly navigate your content if you aren't providing structured data markup.

To see Google recommend this while they're simultaneously pushing Structured Data seems odd to me. Maybe they want everyone to do it with JSON-LD instead; who knows.

Sorry, but I'm going to keep using semantic tags that make the structure of my content obvious. P tags should not be hanging out in the middle of nowhere.

> I'd have to test this, but I'm pretty certain screen readers will not know how to properly navigate your content if you aren't providing structured data markup.

Do screen readers operate directly on HTML now?

Because presumably they look at the DOM. And the resulting DOM is identical, whether or not you close your <p> and <li> tags explicitly, or include your own <head>, <html> and <body> tags, or whatever.

Try it.

Yes, the parent of your comment is a typical misunderstanding of screen readers.

Are you sure? Because I do a lot of testing against VoiceOver and it has two modes, a DOM traversal mode and "grouped" mode which parses HTML. The latter will often do really weird things, like look at the ids of your tags.

And this mode on VoiceOver up until 10 years ago was the default.

In the Windows world, yes, you're totally right.

The <head> tag is optional as per the spec.

Although I like to make <body> explicit to avoid ambiguity in case of <script> tags.

All these comments about <head> being optional and nothing about <body> being optional as well? No one noticed it is missing from the recommended example?

The browser knows what a <title> tag is, so no–the head nesting doesn't really matter. That's Google's point.

Reply on news.ycombinator.com