Google HTML/CSS Style Guide – Omit Optional Tags | Hacker News Reader

Google HTML/CSS Style Guide – Omit Optional Tags

google.github.io

473 pointsfranze282 comments

Maybe it will make more sense once it fully sinks in, but I think in general it is a mistake to make developers think about when and where certain things can be omitted. It's more straightforward to simply do one thing, consistently, following the "explicit is better than implicit" mantra.

What happened to optimizing for mental overhead instead of file size? This simply should be a build step, part of your minification and concatenation dance, not having to consider all of these when trying to decide if I should close my <p> tag or not:

A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element.

This reasoning is why I write all the web pages for my personal projects using XHTML. I can't be bothered to remember which tags are self-closing, which tags need explicit closing tags which can't be combined into the opening tag, etc. Everything's consistent in XHTML.

Agreed. Years ago I started doing all my projects in XHTML because I found that debugging silent HTML errors was not fun.

Silent errors include things like malformed tags and attributes, incorrect nesting structure (thus also messing up where CSS rules are applied), and unescaped left-angles and ampersands.

This is why I've always advocated DTD-validation of HTML (which is shockingly underused).

I've never actually seen anyone validate their HTML. If you suggested this in most companies, they would look at you like you had two heads.

About a decade ago it was a pretty commonplace thing to happen.

HTML 4/4.1 was kind of messy, and could have rendering issues. So going with an (x)HTML validator was a common thing, as well as a marketable value proposal to clients.

HTML 5 had much "saner" implementations, so validators fell by the wayside as they weren't as necessary for compatibility.

A good text editor will validated against the DTD as you type. And after you publish, you can use https://validator.w3.org/

The Firefox source viewer (not the developer tools DOM viewer) does validation. It will highlight bad tags in red and if you hover over them it shows the error.

I'm pretty sure Moz has HTML validator built into its SEO tool, so it may be more common than you think solely because of that. We validate HTML at my company—If we don't we'll hear about it next time our boss runs an SEO check,

How can you validate HTML when most of the HTML these days is templated and generated dynamically?

It turns into a complete document eventually.

It's why I stopped using hand coded markup at all, aside from markdown for article data. Everything else is data pushed into templates that generate "whatever the code is that the client needs to receive", and let the build tools figure it out. That's what they're for.

As long as you're sure it will never be interpreted as HTML, you can do that. Which is harder than it should be, because doctype declarations are ignored. One lost header or unforseen embedding and everything after that <script /> tag gets eaten.

I've started using haml recently, it handles this for you and works well for me.

You shouldn't have to remember it, but you editor could and should.

XML validators are much more common in editors than HTML validators, probably because XML is both easier to parse and used for a lot more than XHTML.

I write and edit all my Genshi [1] templates as xhtml, so I can validate and process them as crisp clean hi-fidelity xml, and then pump them out to browsers with the html serializer [2].

If I were inclined to follow Google's guidelines on omitting optional tags, it would be easy to write a stream filter that removed them [3].

But I prefer source templates to have all the explicit properly indented structure, so they're easier to validate and process with XML tools (and by eye), and unintentional mistakes don't sneak through as easily.

For the same reason, I also prefer not to write minified JavaScript source code: that should be done by post-processors, no humans. ;)

[1] https://genshi.edgewall.org/

[2] https://genshi.edgewall.org/wiki/ApiDocs/genshi.output

[3] https://genshi.edgewall.org/wiki/Documentation/streams.html#...

If you are writing <p>something <div>like this</div><p> then your editor knows you are making a mistake and can highlight it.

If on the other hand you are not closing tags that autoclose, how can your editor tell you? There is no way to know it's not intended.

The editor could have a setting for that.

But mostly I meant that you don't have to close the autoclosing tags.

interesting - which mime/type do you use?

application/xhtml+xml as it's supposed to be, though it's not that I have a choice since Github sets all the headers.

So you don't? Coz it would be nuts.. I'd wager 90%+ of the 3rd party JavaScript out there will choke on it.

You can use text/html. Technically it wouldn't be an XML resource, but it's correct for HTML5. You can also use an xhtml doctype[1]. And don't forget that the HTML5 namespace is http://www.w3.org/1999/xhtml! [2] So basically you use your xhtml tools and just publish as HTML5.

[1] https://www.w3.org/TR/html5/syntax.html#obsolete-permitted-d... [2] https://www.w3.org/TR/html5/infrastructure.html#namespaces

"I can't be bothered to remember which tags are self-closing, which tags need explicit closing tags which can't be combined into the opening tag, etc"

You're right lets not bother ourselves with this small things, cause === and == do the exact same comparison in Javascript and all browsers are exact replicates when implementing html, css and javascript.

Beyond all the sarcasm, in reality, web programming is a hassle. But other programming languages and markups have their quirks as well. I'm glad you found a solution, but it doesn't mean we shouldn't look at the fine details of a specification.

>cause === and == do the exact same comparison in Javascript

I also don't bother remembering how == works. I use === everywhere. The reason is the same - lower cognitive overhead.

>all browsers are exact replicates when implementing html, css and javascript

The browsers I care about all parse XML correctly.

>I'm glad you found a solution, but it doesn't mean we shouldn't look at the fine details of a specification.

I'm only talking about myself, yes. I only make websites for my personal projects. I'm certainly not a web dev by profession or even by hobby.

I don't understand your argument. Yes, web programming has lots of warts and subtle behaviors and inconsistencies. So shouldn't we jump on a chance to remove a small part of that from our day-to-day development? OP isn't advocating ignorance of the spec, just a way not to need to reason with it as often.

No argument, just a comment that displays my disapproval of not fully complying with the spec before blaming it.

How is anyone not complying with the spec by not micro-optimizing away legal-but-redundant tags?

You already have to consider all of those cases about the <p> tag: because they auto close when they hit one of those elements, that means that <p> tags can't contain any of them. If you don't know about this while using <p> tags, you can be in for a world of fun mysterious issues.

But all those tags are things that no sane developer would put inside a p tag anyways, so you don't really have to think about them.

The real mental overhead is incurred when reasoning about the tag following the p, which could be anything. "Hmmm, I have a nav tag coming after this p tag. Does that implicitly close it?"

Although if you had a good autoindenter, you could catch any mistakes by how it was indented. "Oh, that nav tag is on the same indentation level as the p tag, I guess it does implicitly close it."

I have done web dev on and off for over 15 years and I've never even thought about what happens when you put a h1 in a p. In my opinion the browser should crash and the operating system should BSOD. I have always been severely annoyed by the amount of shit browsers put up with. I don't understand why XHTML strict didn't get the traction it deserved and why they didn't continue along that line with HTML5.

Because the world is made up of messy people. And the value of allowing messy content was perceived as outweighing the value of consistency and reliability. I happen to agree.

I ran into this when working on some software that put user comments in <p> tags. I added some allowed markup that came out as <div> tags for a collapsible section. It didn't strike me as a particularly insane feature, but I about lost my mind trying to figure out why the <div> tags appeared to negate the <p> tag styling for all of the text after it.

> This simply should be a build step

This is a great point, but when I think of build steps, I think of something like minifying which comes with a performance gain.

I'm not sure I see what the obvious gain to omitting optional tags in the way Google suggests is.

Edit: To clarify, I'm wondering if there's some performance gain by the browser not having to parse the implicit optional tags.

How is a build step that turns your HTML into a smaller amount of HTML with the exact same behavior (by removing optional tags) different from a "minification" step that turns your HTML or JS into a smaller amount of HTML/JS with the exact same behavior?

This is minification, isn't it?

Updated to clarify my comment as a reference to browser performance not file size.

Smaller file size -> faster loading (in theory... if gzipped, it's probably redundant).

Possibly faster parsing, because the parser has less HTML so go through. (also probably not valid, because I'd be pretty sure that reading a string from memory is not the bottleneck in parsing, compared to logic, memory allocations, etc).

It could make a difference for Googles server infrastructure though.

If they have to download a tiny bit less, and save a tiny bit on CPU cycles and memory for each page, , it might still lead to considerably savings.

> I'm wondering if there's some performance gain by the browser not having to parse the implicit optional tags.

The motivation behind this style is not browser parsing perf - it's network perf. The smaller your HTTP response, the fewer packets (and round trips) required to transmit it.

If your output is compressed (which it should be if you're worried about response size) then omitting end tags has much less impact, I believe. All of the tags should get compressed well because they're repeated so often, and they should be much smaller overall than your non-repetitive content.

But note that on the scale of move as much data around as Google does, or even "the web as a whole", shaving even a few bytes off of every single gzip packet stream can still equate to significant network relief.

I suspect their advice is for their benefit, not other website devs. They can save a lot of space in their archive if everyone's pages were smaller. Nothing compared to better image compression though.

No - a few bytes on a web page are insignificant compared to the data volume of images and movies. This is all about getting pages to load faster on mobile.

If those extra bytes drop you from two packets to one, that's a _significant_ reduction in traffic

(which, IIRC, was the original rationale behind that style guide rule)

If you would gzip your output like you should, how much does that even buy? There's usually something better to use your time for instead of trying to shave 500 bytes out of your page.

it's not a competition, though. If there's something better to do, also do that. However, that does still leave the question of how many bytes are actually saved in transport, especially with gzipping. The benefit here is absolutely not individual developers or even individual sites, but the data transfered by entire data centers over the course of a day, week, month etc. If this recommendation can bring down the total byte transmission for "the web" by 0.001% for instance, that's still a boatload of bytes that don't bog down the network anymore.

When you're looking at fractions of a percent, remember to consider other options. Set up brotli, for example. Or redesign your site to have a leaner layout. You might not ever reach the efficiency level where optimizing optional tags is the best use of dev time.

And the overhead of tracking which tags are optional in which circumstances is not particularly small. Consider that the extra complexity could impede more optimizations in the future, especially now that your markup requires a more complex parser than it could have needed.

Have you looked at the size of Youtube and Netflix videos?

According to this study [1], 70% of web traffic is video streaming. Only 8% are web browsing (which might include images, because they are not mentioned anywhere else - didn't find any info on that).

This is not going to make any difference.

Just because the vast majority of roads are for cars doesn't mean we should therefore not try to optimize the bike and pedestrian lanes.

Sure, a lot of the traffic is streamed data rather than HTML, but 30% of close to a zetabyte of data in a single day (for the internet as a whole) is still hundreds of petabytes that can be made drastically smaller. When the numbers are that large, even optimizing for something as "insignificant" as 0.01% of the traffic means 10s or even 100s of terabytes not pumped through the network every day.

You sound like you want to act for the good of the whole human beings but we have priorities over shaving the last bytes off our pages.

You would have a better day to let webmasters know to use gzip if they aren't.

As always: optimizations are not a matter a of "one or the other" they're about "do all of them". Make the build tool apply all optimizations and minifications, and make the client-server connection negotiate as much compression as possible. Don't stop at just gzip when further improvements are trivial (like this one).

compression and encryption often don't play nice with each other. See CRIME and BREACH, for example.

The double negative phrasing Google and the spec uses makes it sound weirder than it is. You could phrase it as "only use tags that are needed for the document to be parsed correctly" which makes explicitly including an <html> tag with no attributes or a information-free stack of closing tags seem like a strange thing to do if it wasn't tradition.

file size? It's not much, but it would still strip some stuff.

I'm still bitter that HTML/XML works based off of explicit closing tags (where you can mistakenly close the wrong tag) instead of something like braces.

Use a build tool (which you should be doing anyway if you hand-write any markup, because you need to validate it) and make it rewrite </> to the relevant closing tag, if necessary... problem solved? (and yes, you'd be free to even leave </> off in many, many places: https://www.w3.org/TR/html5/syntax.html#optional-tags).

Alternatively, don't use HTML at all. Use pug (formerly "jade") or something and now you're free from all those inconvenient angle brackets.

After using pug, I don't think I can go back to plain HTML. I didn't know how much i hated closing tags.

Maybe it reduces the load on Google's crawls of the web.

Less HTML to load? Probably makes no difference in most cases, but it is less to load.

Many React/Webpack flows do something like this (minify or use a barebones template HTML).

Seems like something you can add a build step for though. Less human overhead

Sorry I wasn't very clear, that's what I meant by "React/Webpack" flow! See: https://github.com/ampedandwired/html-webpack-plugin

but I think in general it is a mistake to make developers think about when and where certain things can be omitted.

Yes, sometimes it is better to make developers think about when and where certain things are required.

I agree, but maybe a transformer step could do it automatically. Write full HTML, generate less.

After 20 years of composing HTML, the world can do better than write full HTML but use technology like jade and not worry about what goes to the browser...

Why not worry about what goes to the browser? In my eyes, what actually runs in the browser is the only thing that matters in the end. You could still write in something like Jade, transpiler, minify, then strip unneeded tags, all with automation.

I didn't mean not to care what goes to the brower, I meant if tools like jade does it right for us, the rest of us no longer have to care about those little details.

Frankly I'm amazed the HTML way of verbose writing still stands after all these years in a fast paced industry.

Hadn't heard of Jade myself so your post inspired me to go looking. On http://learnjade.com/ the front page example shows that Jade doesn't take advantage of this ability to omit the closing </p> tag. So while I agree with you that html is not the best form for authors to write in, Jade itself still has room for improvement.

Would that be jade's job? I'd argue jade's job is to make writing html easier. Another tool should take on html optimization.

That is an option of course but then requires further processing by another tool. And Jade is often used real time which means that the need for further processing will be a burden. Is there any reason for the tool to output less than optimized code in the first place? What value is there in producing html that needs to be optimized by another tool?

By the way, Jade is in the process of being renamed to Pug because of a naming conflict with someone who holds the rights to the Jade name in another context.

https://pugjs.org

The value is that optimizing would make jade/pug's code more complicated, whereas a generic tool that minimizes html according to these rules would work on whatever preprocessing tool you use (PHP, ejs, erb, handlebars, pug) that spits out HTML.

Do one thing and do it well, pretty much.

EDIT: editting since I can't reply to child post.

The thing is, if jade does it well on its own, then all the other tools won't profit from it. I believe jade should focus on outputting easy to understand, well-indented HTML.

When debugging HTML problems (missing attributes or whatnot) in development, I always disable any kind of minifiers. If jade implements a minified output, it would need to be optional, further increasing complexity.

If minification is a build step, I can just disable that step. Easy peasy.

Yes, that all makes sense. But there is also a cost to such a design. To my mind, doing it well means outputting optimized code.

Edit:

Worrying about the fact that Jade/Pug optimizations won't benefit others completely misses the point. Any improvements to its parser wont help anyone else either. The question is how to make the best tool for the job.

Perhaps the inefficiencies of outputting sub-optimal HTML don't matter much in reality. But if optimal html output was easy to do we would expect it to be done, right? So the only question at all worth considering is how difficult it is to achieve optimal HTML output.

My gut tells me that better output can't be that much harder, but I have never looked at the code at all so I may be dead wrong.

But you don't need or care about optimized html while developing. Much like you only minimize JavaScript when deploying, minimizing the html can be one step in the production build process that you pretty much set up once then forget about.

You still pay the cost in processing time of the optimization tool with every real time request. Pug is adding in unnecessary HTML elements which the next step in the pipeline removes. It's clearly inefficient.

Whether that is really important is another question; probably in the big scheme of things it's not worth worrying about. But I wouldn't dismiss it without knowing for sure that the costs in complexity to Pug are actually significant. That would require someone who knows the codebase to comment.

> A p element's end tag may be omitted if the p element is immediately followed by block-ish element, or if there is no more content in the parent element.

> This doesn't apply if you are doing weird stuff in a non-block-ish element, or a media element, or a custom element.

is the easier way to think about it usually

It's really just better to keep a closing p tag, so you don't have to care about consequence when you edit that part later... Does not type </p> save anything? No.

I honestly prefer it when editing

    <p>
        It naturally acts as a clean way to segment
        paragraphs of text
    <p>
        And most of the tag-closing rules are roughly
        matched with the rules of using p tags altogether.
    <p>
        e.g. you can't have a div within a paragraph, so
        closing or not closing, divs can only come after 
        paragraphs!.

It actually saves at least 4 bytes per closing tag. On a larger webpage, that could easily add up to saving hundreds or thousands of bytes per request. That's a significant savings, especially for mobile.

gzip makes it insignificant.

I just took a sample page out of here which has bunch of p tags open and closed, gzipped the original and the one with </p> stripped, difference was 39 bytes.

https://en.wikipedia.org/wiki/C_(programming_language)

Ironically, if end tags were truly non-optional, html might actually compress better, because it would have less entropy (less choices). In practice, it would allow for a compression filter to represent the tree structure in a less redundant form with fewer corner cases to deal with (much like compressors do for binaries, for example).

Thousands? Over 250 p tags on a page?

It's possible/likely that's what they mean. However the final markup is generated, make it minimal, shout-out to react, packagers, minifiers, etc

I write HAML. It's confortable, resumed and strict. It outputs nice-formated HTML.

This is one Google ad. Any questions?

    <h3><a style="display:none" href="http://www.googleadservices.com/pagead/aclk?sa=L&amp;ai=DChcSEwi36oSzi5fPAhWBh34KHQO2A0YYABAF&amp;ohost=www.google.com&amp;cid=CAASJORo9LOCMjoibKPv7gF6cak7OxiE3TtM_tpkLykYWNps5wdfUw&amp;sig=AOD64_3sHUU366i6dStUuQ_sGYCNCCiv9A&amp;q=&amp;ved=0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQ0QwIJQ&amp;adurl=" id="s0p2c0"></a><a href="https://www.capitalone.com/credit-cards/compare/?external_id=WWW_VI194_ZZZ_ONL-SE_ZZZGO_T_SEM2_ZZZZ_c_Zg_" id="vs0p2c0" onmousedown="return google.arwt(this)" data-preconnect-urls="http://www.capitalone.com/,http://5138.xg4ken.com/" jsl="$t t-zxXzjt1d4B0;$x 0;" class="r-ifxiYWNp1hrU">Capital One® Card Offers - Apply for Credit Card Offers Now‎</a></h3>
    <div class="ads-visurl">
       <span class="_mB">Ad</span><cite class="_WGk">www.capitalone.com/ApplyFor<b>Card</b>Offers</cite>‎
       <g-bubble class="action-menu ab_ctl r-iS1b0Exw3vQ8" jsl="$t t-R7dwiTmE0C4;$x 0;">
          <a href="javascript:void(0)" data-theme="0" data-width="230" class="g-bbll" aria-haspopup="true" role="button" jsaction="r.saTe4DDW138" data-rtid="iS1b0Exw3vQ8" jsl="$x 1;" data-ved="0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQJwgm"><span class="mn-dwn-arw"></span></a>
          <div class="g-bblc" data-ved="0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQKAgn">
             <div class="_lBb">
                <div>This ad is based on your current search terms.</div>
                <div class="_zFc r-ivNjifPqiifI" jsl="$t t-h6cwAtrxkFI$t-wWNthJIwnKo;$x 0;">Visit Google’s <a href="javascript:void();" jsaction="r.8Na6VOGeTa8" data-rtid="ivNjifPqiifI" jsl="$x 7;" data-ved="0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQKQgo">Why This Ad page</a> to learn more or opt out.</div>
             </div>
          </div>
       </g-bubble>
    </div>
    <div class="ellip ads-creative">Find Great Rates &amp; Rewards—Apply.</div>
    <div class="ellip">Autopay&nbsp;·&nbsp;Online Banking&nbsp;·&nbsp;Account Alerts&nbsp;·&nbsp;Travel Benefits&nbsp;·&nbsp;Security Alerts</div>
    <div class="ellip">Services: Apple Pay™, Chip Technology, Second Look®, Image Card℠, Wallet App</div>
    <ul class="_MEc">
       <li><a style="display:none" href="http://www.googleadservices.com/pagead/aclk?sa=L&amp;ai=DChcSEwi36oSzi5fPAhWBh34KHQO2A0YYABAG&amp;ohost=www.google.com&amp;cid=CAASJORo9LOCMjoibKPv7gF6cak7OxiE3TtM_tpkLykYWNps5wdfUw&amp;sig=AOD64_0_5WQ5HIxnRdQEOpUEmdSkkiWV4w&amp;ctype=4&amp;q=&amp;ved=0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQpigILCgA&amp;adurl=" id="ads-0-0-2-1-0"></a><a href="https://findmycard.capitalone.com/?external_id=%7B_externalid%7D" id="vads-0-0-2-1-0" onmousedown="return google.arwt(this)">Find the Right Card</a></li>
       <li><a style="display:none" href="http://www.googleadservices.com/pagead/aclk?sa=L&amp;ai=DChcSEwi36oSzi5fPAhWBh34KHQO2A0YYABAH&amp;ohost=www.google.com&amp;cid=CAASJORo9LOCMjoibKPv7gF6cak7OxiE3TtM_tpkLykYWNps5wdfUw&amp;sig=AOD64_2iwTNF-VPyK96RTweJ4TAggXM4pw&amp;ctype=4&amp;q=&amp;ved=0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQpigILSgB&amp;adurl=" id="ads-0-0-2-1-1"></a><a href="http://www.capitalone.com/credit-cards/compare/?filter=nofee&amp;external_id=%7B_externalid%7D" id="vads-0-0-2-1-1" onmousedown="return google.arwt(this)">Cards with $0 AMF</a></li>
       <li><a style="display:none" href="http://www.googleadservices.com/pagead/aclk?sa=L&amp;ai=DChcSEwi36oSzi5fPAhWBh34KHQO2A0YYABAI&amp;ohost=www.google.com&amp;cid=CAASJORo9LOCMjoibKPv7gF6cak7OxiE3TtM_tpkLykYWNps5wdfUw&amp;sig=AOD64_1AOh7CWEmBWXjNLs4Oondpyt-JAg&amp;ctype=4&amp;q=&amp;ved=0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQpigILigC&amp;adurl=" id="ads-0-0-2-1-2"></a><a href="http://www.capitalone.com/credit-cards/compare/?filter=popular&amp;external_id=%7B_externalid%7D" id="vads-0-0-2-1-2" onmousedown="return google.arwt(this)">See Popular Cards</a></li>
    </ul>

Well, yes, it's hypocritical. But that's from a different team. You don't need to look further than the styleguide to find contradictions: it's advising to omit optional tags in order to "save bytes", then it's advising to indent with spaces instead of tabs.

shrugs should just let minifiers do the job.

Google's standard template language (soy / closure-templates) does mininfy whitespace by default [1]. However, it does not omit optional tags. I think this is why the style guide is written as it is.

Still, I agree that both types of optimization / minification should be done by the tooling layer.

[1] https://developers.google.com/closure/templates/docs/concept...

It doesn't advise only for saving bytes, but also for scannability, which is greatly enhanced following that advise.

Are we supposed to think this is too much HTML for one ad? Because I don't think it is.

A lot of it is URLs, and of course you have to have full URLs on an ad, you can't use relative.

As for the number of elements, there's quite a few divs but there's also more elements to an ad than people realize due to the built in reporting interface.

Sure a simple banner ad might be able to get away with only two HTML elements (an anchor tag and an image tag), but that image will end up being a lot more data than a text ad with as many elements as this one.

To quote one URL http://www.googleadservices.com /pagead/aclk? sa=L&ai=DChcSEwi36oSzi5fPAhWBh34KHQO2A0YYABAF &ohost=www.google.com& cid=CAASJORo9LOCMjoibKPv7gF6cak7OxiE3TtM_ tpkLykYWNps5wdfUw&sig=AOD64_3sHUU366i 6dStUuQ_sGYCNCCiv9A&q=&ved=0ahUKE wiswYGzi5fPAhVSVWMKHYoQDjQQ0QwIJQ&adurl="

Thats about 300 digits from an alphabet of 0-9a-zA-Z which my computer says allows for "NaN" unique combinations. They could shorten that by 95% percent and still give every atom a unique id.

... and thats just one URL. There are 4 or five more. For three lines of linked text.

Such long Base64 URL parameters usually carry encrypted data. So they might be impossible to shorten.

What does the first <a> tag do? It's empty and is not displayed. There's nothing inside it. What click triggers it?

It's possible that there is also a script that alters the markup after the page loads.

No, that's extracted from the DOM using Firefox's DOM inspector.

It could be manipulated onhover

It doesn't take up space. You can't hover over it.

I've seen this sort of thing for fraud detection before. Given that they make money off of clicks, that seems important.

Most likely. It is sometimes also used with forms as an easy way to detect bots: an extra input with a display:none is used to filter out bots submissions.

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?

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?

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).

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.

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.

The non-normative HTML 5 spec declares those words, ostensibly because <p> elements cannot contain other block-level elements, and so the user agent should infer a </p> tag when a block level open tag is seen within a <p> element.

I've always been of the school of thought that it's a bad practice to depend on non-obvious behaviors that, when taken in the context of so many other rules that are explicitly defined, seem like a bug that's been codified into a de-facto rule.

Granted, <p> elements are special snowflakes in the specification (not seen as precisely a block element — because it's more limited in allowed content, a phrasing element, an inline element, etc.), but most online docs refer to it as a block level element, and in block level elements, you don't omit the closing tag.

Say what you will about XHTML (such things, I'll add, I'd likely join you in saying) but at least it had one thing going for it: a well-formed document was easy to test for. Note, I didn't say valid, I said well-formed. For that reason, I still write HTML as well-formed XML for easy linting, and then a tidy step later to turn it into plain-vanilla HTML (though, generally speaking, that last step isn't necessary).

It's a real shame HTML5 ever became a thing. We would have been a hell of a lot better off with a simpler spec - perhaps not xhtml as is, but certainly one that keeps the simplicity of well-formedness around.

Such a mess nowadays - and it's not just `<p>`, similar special snowflake rules exist for `<a>` and `<button>` too, and indeed lots of elements have special quirks that make composability a pain.

I think Acid2 was partly responsible for this. See https://hsivonen.fi/last-html-quirk/

Like many other commenters have said, it makes a lot more sense to have this in a build step rather than doing by hand -- there's a lot of somewhat arbitrary rules (see when you can omit a "p" closing tag for example) that can be explicitly handled during building.

However, what does this really accomplish? Does it really save that much space and bandwidth? GZIP compresses text extremely well, so I don't see the usefulness in most cases. Sure, for really slow networks, e.g. in developing countries, it might matter, but the people that this guideline are targeting are likely not going to worry about that. Maybe at Google scale it makes a difference.

Beyond that, it really feels weird to omit the html tag and the head tags and I'd like to see how much more readable this optional tag omission is when you're dealing with a complex page with many meta tags and a ton of body content.

I've been omitting needless tags since HTML5 became a thing and I'm totally over any residual "weird feelings" from the XHTML days.

> Sure, for really slow networks, e.g. in developing countries, it might matter,

#thirdworldproblems, eh? There are more third-worlders than there are visually impaired people. Do you also disregard the blind?

> Does it really save that much space and bandwidth?

I would think on Google scale saving a byte is like couple hundred dollars or some other non-trivial amount (but at same google scale this is pennies).

Then again, if Google homepage is 5 bytes less, gigabytes will be saved delaying heat death of the universe or something… :)

As somebody who does a lot of xml, I'm weirded out by the idea that the root tags are optional. I mean, get certain child elements and attributes being optional, but the parent ones? That's.... hard.

It reminds me, and not favorably, of all the old laziness that made browsers' DOM parsers such nightmares of special cases upon special cases, and all the extra effort to deal with that which was so much the norm last decade. Perhaps this isn't a regression, but it certainly feels like one.

That's a big part of what HTML 5 is about, to codify existing practice when it was realized that trying to push strict standards was fighting against windmills. Nobody would ever push their web pages to the browser as application/xhtml because the user getting a validation error instead of a working page due to any slight infraction would have been catastrophically poor UX. Thus, even "XHTML" pages were sent as text/html and parsed by browsers as tag soup - pretty much defeating the purpose of XHTML.

Browsers accepting tag soup is just a manifestation of the Robustness Principle [1]:

"Be conservative in what you send, be liberal in what you accept"

[1] https://en.wikipedia.org/wiki/Robustness_principle

But this style guide wants you to be liberal in what you send.

Not really liberal - leaving out those tags is perfectly fine according to the specification and all compliant browsers will create the same DOM from it.

Would it allow some performance optimizations on browser if it could assume the content is valid xhtml and simply barf if it is not, instead of trying to make sense of it?

Not really. Ultimately, once you get beyond the HTML parser you're just working on a DOM and other data structures derived from it. And unless you made the DOM much stricter, you could always end up with an invalid (i.e., doesn't match the schema) tree through use of scripting, so you still need to handle it.

It probably would make the parser simpler, however, which may well be faster. And xhtml is closer to the dynamic dom in semantics than html, by virtue of not having self-closing issues or nestability issues (i.e., you express nesting a button in a button with the dom and xhtml, but not html).

It wouldn't really make the parser much simpler. Your state machine goes to having a branch for a character c leading to a fatal error instead of having a branch for a character c leading to something getting added to the DOM. Honestly, the biggest gain I'd expect perf wise is better cache locality for the parser.

(Also, I'll point out that HTML allows the parser to abort at any parse error it defines, the first time it hits that parse error. So you can implement a relatively strict HTML parser that rejects content and have it comply with the spec.)

HTML also defines extremely flexible error recovery that is de-facto required. There's no way a browser's getting away without it when the competition allows such documents, and there's so much legacy content around.

I wouldn't expect huge perf increases, but there are a few minor non-local effects such as self-closing tags that imply more branches than strictly necessary. It's not going to add up to much of anything, that's for sure. A simpler spec might, however, leave more complexity-budget for clever optimizations, but that's pretty speculative. The kind of thing I'm thinking about here is that when the language is fairly restrictive, you can consider using SIMD operations to match content cleverly; e.g. you might find the closing quote of an attribute four-chars at a time. Those kind of tricks require interplay decoding and parsing and are typically way to complicated in all but the simplest of cases.

In any case, this is drifting off topic: perf is not a primary reason to aim for simplicity, it's just a possible windfall.

People have definitely done work on using SIMD for HTML parsing, FWIW. There's plenty of places where you can easily do it, especially in what tends to be the most expensive tokeniser states.

Why didn't they decide to keep the strictness, but only in dev mode? Lets say after you checked some checkbox in browser settings or if you had dev tools opened.

"keep the strictness" from what, though? Presto-Opera reported parse errors in the dev tools, for example (parse errors have a clear, unambiguous definition even in the current HTML spec).

DTD validation? As far as I'm aware, it would only be keeping it at a spec level—no implementation aside from validators ever implemented it. There's nothing stopping a browser from noting any validation error, though (and note they wouldn't just happen at parse time—they could happen following any DOM modification).

It's weird if you're accustomed to XML, but most file formats, even those representing hierarchical data, don't have a root-level "wrapper". Most file formats have a header followed by one or more data sections possibly followed by a footer. Of course, in a hierarchical document format the run-time binary representation will constitute a tree, but there's no intrinsic reason for a serialized format to be isomorphic to the run-time format, as long as possible missing pieces can be inferred on deserialization.

As someone who used to work a lot with XML, I was annoyed to bits by XML parsers forcing me to always use tags that a parser could trivially infer from the target document model. Especially since XML was (and still is) for data transmission, and absolutely not for data storage, it always struck me as an incredibly wasteful approach to transmission data packing.

To me it makes total sense. I mean why would you have a root tag? You already know it's an HTML file due to the mime type. It's redundant information with no meaning.

Your comment seems based on the article suggesting humans should handwrite HTML like this, which I don't think is the intention here. Somebody else posted about the spec description of open <p> tags and there is no way you'd want to have that in mind when writing markup, just close the tag. This would be like a more powerful form of removing trailing comas, which is "neater", but is extremely painful whenever you're refactoring and moving things around.

You say the HTML tag has no meaning, but it has the advantage of being explicit instead of implicit, as well as universal.

There are situations where implicit is better, because the explicit way feels like a big waste of time and demotivates developers.

There is also a lot of value in conventions, as all the efforts around coding standard and linting tools show. It forces different people to work more similarly, using an established way to do things instead of their own quirks, facilitating collaboration and sometimes educating them about the features and caveats of whatever they're using.

I've never been annoyed writing <html>, <head>, which happens a handful of times in the lifetime of a project that I'll spend thousand of hours on.

Again, I don't think any of this is relevant here, as those optional tags would be cleaned up at build or rendering time, and reinserted by the browser / parser. This seems like an awful lot of computation to save a few bytes though, but maybe processing power is that cheap nowadays.

Well, I don't need to remember all of them, I can just remember the ones that I find convenient and use them. In the end the validator will tell me whether I messed something up. While you're right that I won't write <html>, <head> very often I can very well imagine that skipping </td> and </tr> is convenient in many situations.

That's the styleguide that Flask and other pallets docs always had for many years already. People keep opening pull requests to change it and are always surprised when I point ou that it's not only not wrong but also by the spec.

If you consider how the parser for HTML5 actually works many of the closing tags you would encounter don't actually add any value unless you have some trailing text that should be attached to the parent node.

Do you have a linter or some such automated style guide that you use to enforce this style?

Not really but pretty sure that's the default serialization of html5lib.

For now. It's likely to change however, as it makes the tree less likely to round-trip. (html5lib essentially follows what the Writing HTML Documents section non-normatively states, but this is only actually true provided the document matches the schema. There are plenty of invalid cases where it causes it to not round-trip.)

FWIW, there's also some trees which are impossible to serialise in HTML-without-parse-errors which I don't expect to ever round-trip, though all such trees also fail to match the schema. A trivial example of this is `<a><table><a>`, which ends up with an a element as a child of an a element (and is, far as I'm aware, the only way except for scripting to create such a tree).

I know that HTML5 deliberately throws out the SGML heritage (to say nothing of XHTML) and makes all of this valid, but this just feels like another micro-optimization that Google promotes because at their scale, every little bit helps.

Besides, isn't this "visual redundancy" (not to be confused with semantic redundancy) is what compression is supposed to solve, and has been solving since, effectively forever? So that we can code to reduce our (and the 'view source'-reader's) cognitive load, and let gzip or brotli or whatever new scheme work its compressive magic before it squirts our payload across a newfangled binary HTTP/2 protocol?

But the SGML heritage is what makes this valid, and it is common in other SGML doctypes. (e.g. if you download OFX data from your bank, the closing tags will be omitted from certain elements.)

Both the optional closing tags for P and the optional opening tags for stuff like HTML, BODY, TBODY, etc. are present in the HTML 4.0 DTD too. (A TR element cannot go in a TABLE element, there is an implicit TBODY.) And SGML, HTML, and optional tags go back to before XML existed.

It is not new in HTML 5. You could omit a lot and have perfectly valid HTML 4.01 Strict too.

The styleguide mentions "scannability purposes". It doesn't say whether it's machines or humans doing the scanning, but I can definitely see the benefit to the latter.

Code is read many more times than it's written. Removing unnecessary noise makes it easier to read.

Compression for HTML has some nasty security consequences (attachs with funny names like CRIME, BREACH, TIME, HEIST) and nobody has any good idea how to solve them. We may see more practical attacks on that in the future and may be forced to remove compression in many cases.

I've been omitting optional tags for a while.

One thing I've noticed is that bing webmaster tools will report "The title is missing in the head section of the page" when there is a title, but no <head>. Maybe bing can't properly crawl pages without a <head>. Another service I've used had the same problem, but can't remember which.

So it might be worth being careful with omitting <head> - and maybe other tags, I'm reconsidering whether it's a good idea.

In the grand scheme of things, this feels like throwing the baby out with the bath-water. The example shows a huge savings in file size, percentage-wise, because it's an extremely contrived one, being optimized for making sure these sort of optional things are a large proportion of the total document.

Real documents don't look anything like this example. They have lots of meta tags and they have footers and they are expected to be read by a wider variety of user agents than "Google Chrome on Windows" and "Google Chrome on Android".[0]

Part of the problem is that we treat HTML as a canonical data format, when it should be a rendered data format. That's not to say that you shouldn't hand-write HTML for your small site[1], but if you're deploying more pages than can be managed by hand, then you should be A) use a data format for your content that is as rich as absolutely possible, and B) statically rendering that data down to a transmission format.

[0] I shudder to think what screen readers might think of this sort of markup. I mean, I make VR applications in the browser, but I still make sure the data is semantic. It's our duty to do so.

[1] AKA "the vast majority of cases". I whole-heartedly believe that new ventures--before it is known how large they will be--should be hand-written.

[3] Popular web frameworks will suffer.

Interestingly they don't seem to have a rule against one line declarations.

I alwats use this style, which imho is very handy, because of the tree structure and admittedly because I have a super cool macro in Vim that copies the characters from the line above, word by word so create rules that afect children of the rule above it requires just a few keystrokes:

  #some-div { margin:1em 0; }
  #some-div .inner { padding:5px 10px; }
  #some-div .inner p { font-size:90%; }

This makes the structure of the declarations more obvious imho, and I tend to have a nicely organized series of structures like that that are logically grouped together.

Obviously this applies more to components/widgets than the basic rules and layout.

If a declaration is long then I use newlines.. but even then I tend to group things together eg.

  #some-div {
    display:inline; margin: ...; padding: ...;
    border-radius: ...; border-color: ...; 
    font-size:90%; text-align:center;
  }

Basically within a css rule I'll group together the layout properties, the text properties, etc.

The first example is fine, if you're only setting one property then doing it in a single line isn't a big deal.

Your second CSS example is no bueno. Don't put multiple properties on a single line. It might make sense to you to put display and margin and padding on a single line but it might not make sense to me. These should all be on separate lines, it's not worth "saving lines" to make your CSS harder to parse for someone who doesn't already know that you like to group X, Y and Z properties.

> it's not worth "saving lines" to make your CSS harder to parse for someone who doesn't already know that you like to group X, Y and Z properties.

Well somewhat in between you could also put properties in alphabetical order as suggested in this Google Style Guide. That tend to work for me since "text" properties will be towards the end of the rule, and for me the layout properties like border, display, margin and padding is something I'd want to see first.

But where I prefer some freedom vs hard rules is that I'll also align properties to make the differences more obvious. In this YUI2 example, the second class is applied to a mobile version of the dialog, the common properties come first, that way the difference is obvious:

  /* dialog body wrapper for extra css styling (.rtk-skin-dlg .yui-panel .bd .body) */
  .rtk-skin-dlg .body { background:#fff; padding:10px; border-radius:3px; box-shadow:0 1px 3px rgba(0,0,0,0.2) inset; }
  .rtk-mobl-dlg .body { background:#fff; padding:10px; }

Well that is the whole point, I wish I made the example better.

How is it harder to parse? Putting everything in separate lines make the CSS file 10 times longer, and it's more difficult to see groups of rules that fit together along with their common structure.

Nowadays unless you edit on a tablet your text editor probably handles 120 columns or more.

But I really can't see the argument for readability. When I navigate a stylesheet for a website I'm working on, I want to see the larger structure. I don't need to see clearly the properties within a single rule. I want to see from top down.

Still, this could be argued forever. Apples and bananas :) I guess it's the same discussion as space vs tabs, or 2 space vs 4 spaces.

Here's a better example from one project which used YUI2 (it's old, but I think it shows my point of view, that the dtk-skin-dlg structure is very obvious along with the hd/bd/ft structure YUI 2 uses and the styles applied to them, that's the structure I want to see readily when I work in a stylesheet without having to scroll to understand it's all connected together):

  /* dialog body */
  .dtk-skin-dlg .yui-panel { outline:none; }
  .dtk-skin-dlg .yui-panel .hd { font:16px/1em Verdana, sans-serif; color:#ddd; padding:10px 10px 0; background:none; }
  .dtk-skin-dlg .yui-panel .bd { padding:10px 10px 10px; background:none; font-size:12px; line-height:19px; color:#000; }
  .dtk-skin-dlg .yui-panel .ft { padding:5px 10px 10px; background:none; font-size:12px; line-height:1.2em; color:#000; }
  
  /* dialog footers, right aligned */
  .dtk-skin-dlg .ft-right { clear:both; width:100%; padding:5px 0 0; text-align:right; }
  
  /* left align buttons INSIDE ft-right */
  .dtk-skin-dlg .ft-left  { float:left; text-align:left; /*padding from ft-right*/ }
  
  /* dialog body wrapper for extra css styling  */
  .dtk-skin-dlg .body { background:#fff; padding:10px; border-radius:3px; box-shadow:0 1px 3px rgba(0,0,0,0.2) inset; }
  .dtk-mobl-dlg .body { background:#fff; padding:10px; }

> Putting everything in separate lines make the CSS file 10 times longer, and it's more difficult to see groups of rules that fit together along with their common structure.

You block them together just like we do with code. Good code doesn't put multiple statements on a line, good CSS doesn't either. File length means nothing, if someone's looking for a specific class there are tools to do that, saving a few lines and making the CSS harder to read and edit isn't worth it.

The examples above are much more readable like this (margin added for illustration of grouping related properties):

    .dtk-skin-dlg .yui-panel .hd {
        font: 16px/1em Verdana, sans serif;
        color: #ddd;
        
        background: none;
        
        padding: 10px 10px 0;
        margin: auto;
    }

Written that way, when someone finds that rule in the file they can easily parse the relevant property without having to scan a 200 character long line.

I like to put many attributes on one line too. It fills the page better, making it easier for me to take in: 80 characters wide by 50 lines long, instead of 20 characters wide by 200 lines long.

Agree, this is one of the reasons going for it. Unless someone works on mobile or some small laptop, the text editor should display 120 columns or more easily. And I'm not writing a git commit message, I'm writing css rules.

Besides I like that it also gives me a better sense of how verbose some of the rules are and if some of the properties could be removed entirely. When the hierarchy of those rules is more apparent with the more compact style, I'm more likely to see unnecessary properties (which are inherited) and therefore trim up the code.

I'm very interested in that vim macro.

Sure. This is one of the most useful macros I found online :) I'd love to link to the original page but I can't remember where it is from. Here it is:

  " Piece-wise copying of the line above the current one
  :imap <C-L> @@@<ESC>hhkywjl?@@@<CR>P/@@@<CR>3s

The only reason you would do this is to save space (ie minify). Out of everything you have in your entire stack is the 1kb you save by removing the optional tags really gonna matter? I mean wouldn't it make more sense to spend time reducing javascript, or css styles, or making your database faster?

I mean if you are Google, yes that 1kb matters a ton. But they've already optimized to the point where minifying their HTML makes sense.

Year 2016: 4.5 G Networks rising, Smartphones with 1440P Screens are normal and many pictures and videos distributed in 4K resolution.

And you really think about minification of html, js, or css to save some bytes?

Well Google might, if they serve those bytes a trillion times per year.

google did not serve them (ok from cache), google must read them and process the content, that cost google time and money.

I just wish we had bigger MTUs to fit our bandwidth so we could reduce latency...

Bigger MTUs would increase latency but also increase throughput.

Right, I'd like to see some evidence that omitting tags has any actual value whatever. If you're starting something new and the tags truly are optional (something I don't have a lot of confidence in, but maybe so), then sure, I guess leave them out. But I really question the motivation of this. Saving a few bytes of HTML is a really, really questionable win.

You miss the big picture of "the web" rather than "a dev", or "a web site". The more pages, across all devs and all websites, that build their content in a way that omits the optional tags in HTML, the fewer bytes we have that need to be pumped through data centers and routing paths on the planet.

It's not so much about "if you're google" but "if we all do this": a 0.001% reduction in global byte transfers would constitute a massive saving despite looking like a tiny number.

One thing I don't quite understand is omitting protocol. If you don't know the protocol, fine it makes sense to omit it. However if you know a resource can always be loaded via HTTPS (eg from CDN), isn't it safer to force HTTPS?

I think you're right.

http://www.paulirish.com/2010/the-protocol-relative-url/

This page outlines the original argument, as well as the updated reasoning that you suggest: always use HTTPS if it is available, even if requesting from a page served over HTTP.

My best guess would be that any work done by a Googler will be served up from a domain included in the HSTS Preload List (forces SSL in most browsers)

I always omit the protocol because I develop on a local server using HTTP, but deploy to a remote server using HTTPS.

I agree, the protocol part seems pretty outdated.

here is an edge case: the <head>-tag might be optional, but HTML elements do have a different behavior when placed in the <head> section or the <body> section.

namely, the always beloved <noscript> tag https://developer.mozilla.org/en/docs/Web/HTML/Element/noscr...

which is a flow content element in the body section

but if used in the <head> it might include links, style and meta-tags and then it should not be treated as content element.

as the <head> element therefore changes the behavior of its child-elements, does this make it non optional?

p.s.: i think DOMParser.parseFromString() in Chrome gets this <noscript> behaviour wrong in some cases (closes the <head>-section as it treats the <noscript>-tag as content-element, even though it is in the <head> with just links & style children, so it shoudn't close the <head>...)

replying to myself like a pro: after reading the spec https://www.w3.org/TR/html5/scripting-1.html#the-noscript-el..., the <noscript> element is even trickier, it has at least 4 parsing modes:

in the head with scripting disabled (no text, only link, style, meta)

in the head, with scripting enabled (can include text (like whitespaces) but parsed elements must result in link,style,meta DOM only)

in the body with scripting disabled (text, but no other noscript)

in the body with scripting enabled (text, but no other noscript and script tags)

so basically

  <html><noscript><link href="e.css"></noscript><title>hi</title><h1>ho</h1>

would be find, as the <head> would close just before the <h1> (in scripting enabled and disabled case)

but:

  <html><noscript> <link href="e.css"></noscript><title>hi</title><h1>ho</h1>

would close the <head> in a scripting disabled case just before the <noscript>-tag

and closes the <head> just before the <h1> in a scripting enabled case.

this would explain the DOMParser.parseFromString() behaviour, as it's a scripting disabled case....

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/...

In Chrome Canary 55.0.2866.0 the noscript element contains a text node and a link element. This matches the spec as far as I can tell; whitespace is allowed in noscript in head.

Ok, I've juste discovered that in the html5 specification you can omit tags. I've always been reluctant to push Jade to my coworker but it makes much more sense now.

This was legal for ages. Why do people think this is HTML5 feature? This http://rimantas.com/bits/minimal_html.html dates back to 2005, but of course it was possible well before that.

Sidenote: "jade" is not a thing anymore. For legal reasons that no one understands but are in the past, the thing you're thinking of is called "pug", and lives on https://pugjs.org

To me this just prove that wether a spec or standard is in place. it does not really matter.

In this case we have the weight of Google that says "oh it's in the spec so we can do it".

In other case we have a standard like E4X, that everyone happily not implemented (Chrome) or removed (Firefox).

They could as well say "If we don't like it we will not do it, if we like it we will do it", that would be exactly the same.

almost. It would be exactly the same if it was "If we don't like it we will not do it, if we like it we will do it, and in both cases we set up a w3 working group for writing the formal declaration that this is what we now agree on".

Welcome to HTML5: a document that comes out of the work of tens of thousands of people across decades of historically-encumbered practices. It's done remarkably well, and if you actually read the spec, is way more sensible than you would think that development track would give us.

You won't see this in too many C style guides:

Emit all optional parentheses in expressions, unnecessary "break;" statements at the end of a switch, the type specifier keyword "int" when "unsigned" is already present in the declaration and other such fluff.

I've done plenty of web scraping in which it was helpful to look for the <body> element.

While we're at it, how about we lose the unnecessary uppercase for the doctype: <!DOCTYPE html> vs. <!doctype html>

Leaving out optional tags makes sense. These days, at least with web-apps, It's not like we are writing a <head> for every page. It's just a partial you rarely ever interact with anyway. Either leave them in or take them out. The only negative I could see is that some people may not know what's optional–think you're a dummy–and put them back in. Probably best to just follow the conventions of whatever framework you use. Save your fighting energy for trailing commas in JSON! :)

Capital letters for the word 'doctype' are not mandatory for HTML, only for XHTML.

https://html.spec.whatwg.org/multipage/syntax.html#the-docty...

Yes, think about all those bytes we could save by not sending doctype as uppercase!

In XML, it's required uppercase. Unlike HTML being lax on tag structure, there is no reason to advise DOCTYPE to be lowercase. It's not "better".

I'm not actually fighting for it... or talking about bytes. I care more about keystrokes. My fingers seem to prefer lowercase. OTHERWISE I can just SOMETIMES write THINGS in weiRD cASEe FOR no REASON.. but I have to hold shift or use caps-lock and "I'd prefer not to." https://www.youtube.com/watch?v=U-9tAqdd_4Y

However weird it feels, this makes sense. Why did we ever have do things like use an HTML tag immediately after declaring the DOCTYPE as HTML anyway?

Because it's easy to go "well this was completely unnecessary" 30 years after the fact. HTML's been through decades of change involving tens of thousands of opinionated experts. We have the history we do because this is where we are today.

Well, the HTML tag is older than DOCTYPE. Andin SGML and, later, XML, the document must contain a single root element.

The html element's tags have been possible to omit under all SGML-based HTML standards. This has no bearing on the document having a single root element. (And the document still does have a single root element in current HTML.)

For the love of god, can we please move on to more pressing matters.

The Google JS Style Guide maybe? https://google.github.io/styleguide/javascriptguide.xml

I'm a part time developer that is still at uni but learning the ways of how maintaining code is doing in a professional environment.

Just curious, how often are practices like these where the company you work for gives you a detailed overview of all the coding conventions you should follow? Is this absolutely expected to be followed strictly when you start any job as a developer? Is this something a lot of workplaces follow or mainly the big boys(Google, Facebook, Twitter, etc). If you miss maybe one or two coding conventions in a huge commit for instance, do you hear about it or does the reviewer just fix it and you can see what's changed?

Just curious as I'm still new to transitioning into the workplace when it comes to source control. I work with one other developer (my boss) who wrote for more or less the entire system himself and there is no such document - I just have to observe the patterns used and follow suit.

It's unusual to have style guides, in particular as extensive as this, except at places that have their act together.[1] Where some sort of style is enforced, though, it's typical to have an automated tool that validates your code. This can happen locally (as a pre-commit hook), remotely when you push a branch (as a CI check), or when merging to master (same). If people are going through and noting style guide violations in a code review, that's generally a bad sign.[2]

[1]: This is my opinion. Anecdotally, places with style guides tend to have better engineering cultures.

[2]: Again, opinion. This tends to indicate a weak culture (dictatorial lead or a lack of awareness/ability when it comes to tools) and can produce a negative atmosphere (nit-picking isn't fun).

That's really interesting, first I have heard about automated tools to validate code.

Are there public tools out there you can use prior to commits for this purpose or are they generally done in-house?

The big one for Git is Overcommit[1]. The tools that it runs depend on the language, though. Some are community-driven[2], while others are baked into the language.[3]

[1]: https://github.com/brigade/overcommit

[2]: E.g., flake8 for Python: https://pypi.python.org/pypi/flake8

[3]: E.g., gofmt for Go: https://golang.org/cmd/gofmt/

It looks counter-intuitive, though -- even if it is the spec. Especially for beginners, who might feel completely out of place. As other people have pointed out here, it's better to be implemented as a step of the build process if you really want to save on those bytes. Counter-intuitive patterns are nightmares for devs.

I don't think it's obviously more counterintuitive than the strict XHTML insistence on exact explicit hierarchy.

Like, when you start a new paragraph it doesn't become a new "subparagraph", it just ends the current one and starts a new one. I really don't think it's hard.

I do think omitting needless stuff creates more compact documents with less redundant boilerplate that distracts the eyes.

This is bad advice for the vast majority of sites. It's like, "morbidly obese? Lose weight by not licking stamps!"

Omitting `<head></head>` saves 13 bytes, assuming gzip didn't help in the first place. The average page weighs thousands of bytes, according to https://www.sitepoint.com/average-page-weight-increased-anot...).

If your pages are like the average, you've already wasted too much time thinking about this. Go optimize your images, use less JS, and make 200 other size optimizations first. You'll probably never get around to this one.

In-spec or not, I don't like it

This should be an optimization step performed by a tool anyway.

It isn't?

I'd have assumed someone with Google's resources would have produced at least a linter, if not a fmt tool to enforce these rules. Have they not?

It's worth pointing out that this style rule itself is optional, which is to say they're not making a recommendation here, just providing an example of what applying the rule would look like. It carries the same weight as, say, the optional rule about grouping CSS sections and including a section comment[1].

[1] https://google.github.io/styleguide/htmlcssguide.xml?showone...

https://google.github.io/styleguide/htmlcssguide.xml?showone...

How is adding a space after ":" any more consistent than having none? No space between property and value is more unique and searchable should you need to find something or do search/replace.

They are not saying that the space is more consistent than having none, just says that you always should use one style consistently (and that this specific style guide has chosen to add one space as the thing to do).

I can imagine many html crawlers and parsers breaking for these pages, searching for <head> or <body> but nothing to be found...

Well, it took several decades, but standardized html parsing is now actually fairly robust. So you may not be wrong, but anything that breaks is probably heavily outdated and probably not worth much to anybody (because it's parsing html different from browsers today, and it's not like optional tags are a new thing...).

I wouldn't get too worried about crawlers and parsers.

I'm surprised no one has compared this to omitting semicolons in js. In both cases it's a rather lengthy list of conditions the writer needs to know about in order to be absolutely sure you're coding correctly, and in both cases the benefits are debatable. (The list of conditions when js semis can't be omitted are obscure at least.)

This to me is like:

if (x) { ... ... } someMethod()

Changed to :

if (x) { ... ... someMethod()

It's not as readable. Maybe as others have suggested, leave it to a compiler.

The difference is that your example is ambiguous. “<p>Paragraph 1<p>Paragraph 2” is not ambigous, and never has been.

Perhaps the option here is to write in explicitly verbose HTML as we do now, and then as you minify assets, so too do you minify HTML. If the last thing the output html went through was this reduction, then you wouldn't need to worry about developer overhead.

The Google HTML Styleguide people, really should inform google.com that they are bloated.

Here's my page loading pattern, please tell me if this is good:

In the head tag, I intentionally load a small bootstrap javascript bundle (~50K) non-deferred. This bundle contains a subset of my CSS that styles all of the static tags the body below will first render with. This bootstrap bundle also starts an AJAX call for polyfills, if needed, and the main page script (which also contains the rest of my CSS.)

My goal is to have no unstyled tags in the body as it first renders and to kickoff loading the main body scripts ASAP before any other 3rd party scripts have a chance to get started loading.

Web technologies are totally not piles of hacks on top of other hacks

Slightly amusing:

HTML4, XHTML: Make sure to include all optional tags, because scannability.

Now: For (...) scannability purposes, consider omitting optional tags.

HTML 4 didn’t require optional tags either. That culture was limited to XHTML.

Google's parent company is still using <head> and <body> tags. https://abc.xyz

This is really going to bother me:

  Use double ("") rather than single quotation marks ('') around attribute values

With so many exceptions and corner cases, doesn't it goes exactly against the aim of a code standard, that is to make the code rigorous and less prone to errors? The prevention of weird behaviors and corner cases is exactly the reason why almost all Javascript styleguides recommend semicolons.

I can get behind this.

This blows my mind. Can't wait to bring this up in a code review.

Hrm, is anybody else's browser not navigating to the "Optional Tags" anchor?

Maybe they should've used their time checking the page instead of replacing single quotes to double quotes.

Yes. Firefox on Android

Firefox on macOS here.

A good video from Paul Irish on the subject http://www.paulirish.com/2011/primitives-html5-video/

Is solid html 5. Html 5 fills all the ambiguous parts of the code to DOM translation so you should give up on regexes, handlebars and such and instead run it through JSoup (or equivalent) and just work on the parse tree.

Honest question: Why doesn't everyone use Jade markup if you already have a build step for your front-end code? It's much faster to write and much clearer to read.

Websites are bloated with excessive amounts of JavaScript and non-optimized images, and this is what’s on top of Hacker News? Frickin’ optional tags? facepalm

cant read the article because my browser thinks its a rss feed. But i want to stress the importance of semantics and clean html. Think alternative output devices like html to speach and future tech like direct to brain io and artificial intelligence. Also if u keep it simple, writing and editing also becoms easier and more available. dont mangle or minify your html. Also keep style out of it (in css).

This all good and nice for Google saving a few bytes, but how on earth are you supposed to specify page language with this scheme for instance.

Very cool. I did not know that stuff was optional.

If its less code to type and send over the network then that's great. HTML 5 is not XML. Which is fine.

scripts in <head> tag works perfectly as well as long as you position scripts above elements you would put in the <body> . I will start doing this!

demo: http://jsbin.com/duqonahiyi/1/edit?html,console,output

Yes, but some places tell you not to do scripts there when possible and load them instead at the bottom of the page because the page loading pauses while the script is downloaded (if not inline) and executed. See https://developers.google.com/speed/docs/insights/BlockingJS

yep, so just position the script at the bottom then. :)

It depends on whether you want to run the script before or after the body!

exactly, that is what I am saying.

Hell, I'mm still convincing people to use <br> instead of <br/>!

what's this style guide even mean when google.com doesn't adhere to it?

Here's the direct github link if you want to fork or star:

https://github.com/google/styleguide/blob/gh-pages/htmlcssgu...

>Indentation

>Indent by 2 spaces at a time.

>Don’t use tabs or mix tabs and spaces for indentation.

Let the wars begin.

This is going to wreck havoc on XPATH selectors across the world.

XPath can't run on HTML5, you have to parse it into DOM first, so there's no problem.

HTML5 does actually support an XHTML serialisation[1] if you need your content to be easily parsed with XML tools.

[1] https://www.w3.org/TR/html5/the-xhtml-syntax.html

Ah, yeah, indeed, thanks for the clarification.

XPath is defined as operating on an XML infoset, not a DOM. And there's no defined mapping from a DOM to an XML infoset anywhere. So really we're in undefined territory.

In reality in browsers, that coercion to an infoset never actually happens, and XPath is matched directly against the DOM, which leads to differences in edge-cases (notably, adjacent text nodes, which the DOM allows and the XML infoset does not).

Why? The elements are still there in the DOM and presumably in an XML infoset you create from the DOM produced from the HTML parser.

Grammar nerd, apologies, but "Google's" with an apostrophe (unless I'm totally missing something). There should maybe be a better way to report this kind of stuff without cluttering the comment stream.

Why doesn't Google produce an html formatter instead of a style guide, like gofmt for html? Applying style guidelines correctly and consistently is much easier to do in software than meatware.

I thought we already got haml, jade, sass, stylus etc... Many points become moot using these.

Things like Jade do not make this advice moot. You can still apply this advice after transpile step.

I didn't say every advice becomes moot with them. Besides, shouldn't transpilers do the process then wherever possible instead of manually... which would be, not our job.

If you make sure everybody runs that program, which again is a meatware problem of at least as great a magnitude.

This just feels wrong. It's like only using one space after a sentence. Somewhere along the way it became technically correct, but there's just this visceral feeling that it's not right.

Omitting tags that 'unbalance' a document or stop it from being valid XML is a very dumb thing to do, even if it shaves a fraction of a millisecond off load time. We're talking about a few bytes of transfer here. Come on Google, you should have better judgement than that.

Not the first time I've seen this suggestion but I just don't understand it. Removing <head>, omitting quotes in attribute values... why? File size, really?!

I hope Google will not punish websites by downranking those of us who still uses head tag. After all, why not take the bold move and tell everyone that <pre> is enough, so the whole html monstrosity could be deprecated and Google could save millions in serving his afs to asketic plain text websites, designed in the mood of the Berkshire Hathaway web presense.

Uhh... I wonder how large the percentage of users is that see a broken site if you strictly adhere to that principle.

A conservative guess would be "about 100%", since every browser (even the shitty ones built over the weekend these days) rely on HTML5-compliant DOM parsers.

Since this code follows the official HTML5 spec to the letter (optional means optional - a parser will do the same whether an optional thing is written our or left off), HTML5-compliant parsers just see "correct data" and convert it into the only DOM it can be turned into.

I think you mean "about 0%" see a broken site in response to my comment. Anyway, I get your point.

However, I am a big fan of the robustness principle: Be conservative in what you do, be liberal in what you accept from others.

So for me personally, the issue is clear-cut. I will keep my codebase as clean as possible/affordable, be it HTML or C++, not relying on quirks that have been introduced to tolerate faults of careless designers and programmers.

Browsers have always accepted "broken" HTML, "tag soup" as it's known, in order to not break existing web pages. HTML 5 simply codifies existing behavior.

This behavior is actually older than HTML itself is:

https://en.wikipedia.org/wiki/Standard_Generalized_Markup_La...

Yeah, true. SGML certainly has some "interesting" features.

The rules are really complicated here. It's best to do this using a minifier instead of through hand-coding.

Sounds like a case of mistaking "a thing" for "the only thing": yes, of course this is a thing you make your build tasks take care of, but then you also make sure that any HTML code that is still coded by hand code (because why would you even still have that anywhere, in real projects these days?) follows your project/club/company/organization/whatever's style guide.

Google probably has their own minifier. The development of such a tool would need to have a specifications page ready. Such as that one.

Boo. Maybe it's over the top but for me the fact that something this awful made it into Google's official style guide tells me the nuts are really running the asylum over there. Was nobody in charge doing web development in the 90s or even the early 2000s? Has nobody there ever been put in charge of a legacy site that was written this way? There's a reason we all agreed to stick to standards and make our HTML verbose in the mid-2000s.

What they recommend conforms to standards and should parse identically in all HTML5 parsers.

Oh my god talk about nitpicking. Yes I realize it's allowed, it's still sloppy and gross.

Technically I could put all my HTML into base64 encoded strings in javascript and then write them to the document, that doesn't mean that I should.

Sorry, I seem to have misinterpreted the background of your initial comment (less human aspect, more browser parsing issues).

It's certainly something you should either do automatically or in a consistent style, not as an excuse to leave out random things if you feel like it.

This is and pretty much always was a part of HTML standards.

> There's a reason we all agreed to stick to standards and make our HTML verbose in the mid-2000s.

I think the failure of XHTML shows that this was in fact not universally agreed. Seriously, when’s the last time you saw a page served as application/xhtml+xml?

It's a screenscraping protection, too.

Documents malformed this way cannot be parsed e.g. with PHP's DOM functions without significant headache.

You seem to misunderstand what's going on here. HTML5 explicitly lists which tags are optional in what context, and the document style presented in the link takes that fact and recommends thus removing any optional tag to save data over the wire. There is nothing "malformed" about this, this is literally doing what the spec says is explicitly valid. Any proper HTML5 parser regardless, of which language its written in or for, should be able to parse HTML5 with optional tags omitted perfectly fine.

If PHP's DOM functions don't work for it, then PHP's DOM functions aren't HTML5 spec compliant, and that should be filed as issues against PHP and fixed by its developers.

These documents aren't malformed they're are perfectly valid HTML5. The problem here isn't the document it's that you don't have a HTML5 parser or that the parser is broken.

Reply on news.ycombinator.com