> This approach may require a grace period to be established as a wider guideline as it’s significantly different from what web developers are typically taught.
Chrome uses its own Blink and V8 now, and there are many cases where developers only design for Chrome and small differences in implementation can be a huge pain in Firefox/Safari.
No professional developer targets a browser when developing a web site unless its a captured audience with no choice. Professional developers follow the specification. Those who do otherwise are only mentioned in reddit headlines and other hobbyist sites.
You're missing my point. Assuming that all browsers correctly implement the specification is naive. I don't have an issues with standards themselves existing.
They are implied. I believe this dates back to when browsers supported non-standard HTML and the behavior of doing it was cemented in HTML5 (like tag soup and so forth.) Since it was based on existing behavior it should work even in old IE, just like the doctype.
The very first draft HTML spec, https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt (June 1993), is somewhat interesting here, because the only element with optional start and end tags is the html element (head and body require both start and end tags, per that spec).
Certainly by the point of HTML 2.0 (November 1995; the first non-draft spec for HTML) all three elements have start and end tags all optional.
The more general ability to omit start/end tags from given elements is a feature of SGML (October 1986), and HTML 2.0 to HTML 4.01 were defined as SGML applications (though approximately nothing ever used an SGML parser for HTML).
Interesting... I have never done this except on small test/toy projects at home. I think the main downside today is probably just that the structure of the document is sort of implied, and it may be unclear to new developers why its possible to style html/body when they don’t exist. It does work consistently across browsers last I checked, though.
Yes, it certainly does. I wouldn’t view it as a huge positive, though; it certainly confused me for a while, especially since synthetic nodes actually exist in the DOM.
This seems like insane advice. Even if it's technically permitted, the HTML5 spec page they themselves link to shows a bunch of caveats and exceptions that make it risky.
In my reading of this, I wouldn't say they "recommend" it, but that they recommend considering it. Their link is quite clear that HTML 5 makes these tags optional and gives an unambiguous mapping onto the traditional structure.
It's optional under certain conditions but those conditions are given as you correctly point out in the link to the HTML standard. While many seem to be focused on what Google says, it's nothing that those of us who read the actual spec didn't already know.
And every web developer references the spec when they have questions...don't they?
It's like not using semicolons in Javascript: it doesn't necessarily need to be about shaving bytes but opting out of optional things that you don't need, especially when the machine adds them back for you.
For example, it keeps your indentation level flat here.
Confusing title; I assumed it meant they were recommending avoiding the <main> tag, which seems weird but OK, it’s a new one and we’ve seen document outline tags get deprecated before. But no — they’re recommending avoiding the <head> and <body> tags! These are literally the first things you are taught when you learn HTML. This seems like a pretty fundamental change to have slipped in here without further explanation. What’s the reasoning?
I know it all adds up, but stripping <html><head></head><body></body></html> seems like a miniscule saving compared to the huge amounts of cruft stuffed into most websites.
That's true. Presumably this is for extreme cases when you really need that extra bit of performance.
Perhaps HTML could have been better designed with performance in mind. Every tag you open (i.e. <foo>) you're supposed to close (i.e. </foo>) which is quite redundant in terms of bytes when you think about it. It is easy to imagine markup languages that minimize the number of bytes the client has to transfer.
I think Google has a set of very specific aims, that aren't so relevant to a lot of other organisations.
Cutting out optional tags will improve page size, download speed etc; something that's obviously important when you're serving so many billions of users.
True, for source code it might be better to leave those in. However, the fact that omitting them is standard-compliant is interesting for automated minimizers.
I tried this for a summer, it really did lead to easier to read HTML... although now when I go back I’m not sure which tags can be omitted and which might be errors. I think it’s probably a net negative trade off but still not certain.
These days Im trying out pug instead, which is similar in a sense: more concise and readable at the expense of other people being certain of its correctness and myself remembering the syntax months later.
I disagree, having these tags give the document a structure that makes it easier for machines to understand. As for indenting, I usually break the consistency and put html, head and body at column 1, starting the indenting for anything inside head and body.
Number two looks way easier. If you were to write code to parse #1 you would just need extra code to ignore the useless tags.
Anyway, parsing HTML is a nightmare, and HTML documents are usually broken in the wild, and browsers still, amazingly, manage to render almost anything you throw at them. I'm sure they all already handle it.
> I can't think of why it would be easier to write software to parse
Maybe you haven't considered it closely enough?
If you look at the specifications, there is a complex set of rules governing the conditions under which a tag may be omitted. These naturally complicate the syntax. Consistency is preferable because it typically results in a simpler syntax.
Consider the following language:
document ::= tags
tags ::= tag { tag }
tag ::= '(' symbol [ tags ] ')'
symbol ::= 'x' | 'y' | 'z' | 'w'
It encodes a document like the following:
(x (y) (z) (y (w (x))))
(z (w (z) (y)))
i.e. a list of trees of tags named by symbols.
Now, try to describe the language that's identical except that the closing bracket is optional if it belongs to a 'w' tag that precedes an 'x' tag. Try even to describe a language where they are not optional, but must be omitted. They'll both be more complex than the language I described above. Now imagine that there are about a hundred such exceptions, as in HTML. Chances are that rather than encoding them as syntax for the parser, you'll complicate the lexer to automagically insert the optional tags, fuzzying the boundary between the lexer and parser.
> Anyway, parsing HTML is a nightmare, and HTML documents are usually broken in the wild
Exactly because the syntax is needlessly complicated.
> having these tags give the document a structure that makes it easier for machines to understand
What is a machine supposed to do with the <html> tag? It's entirely useless and tells you nothing. At best it could be used to identify file type, but the doctype has long since replaced that usage and that still wouldn't justify any reason for the end tag.
Similarly for <head> and <body>. They don't really do anything. There's no machine-useful structure to be had from that.
For some of the optional end tags sure, that definitely helps make things easier for machines to understand. That's why XHTML exists. It's not really used, though, but if you really want easy to understand document structure for machines you wouldn't go anywhere close to HTML in the first place and instead use XHTML.
> This project (google/styleguide) links to the style guidelines we use for Google code. If you are modifying a project that originated at Google, you may be pointed to this page to see the style guides that apply to that project.
These are just Google's style guides for their own code. They're not saying you should do this in your own code.
This is an internal style guide, not external recommendations, as the title would suggest. Comments like these are really making me wary of the level of groupthink on here.
Now this makes sense while on my one page website such an omission would save the user like 10 bytes of extra data, when you add up the surface area of all Google properties that extra 10 bytes adds up across billions of page views.
I vaguely remember years ago google.com omitting tags to strip file size and there being some mild controversy around it. Pretty sure it was before HTML 5 adaption and don't think back then the tags where optional, just that browsers try to interpret whatever mess is thrown at them.
To be clear, for anyone confused about the "main HTML tag" in the title, this recommendation is essentially to eliminate <html><head></head><body></body></html>.
I think this sort of things should be done by some html minifier, not by a human. Because the omission rules are not trivial, and removing these tags doesn't really help readability.
"Omit head and body tags, & type attributes to reduce filesize..."
I'm pretty sure you could remove all the head and body tags from the entire internet and it would still make less of a performance impact than if every WordPress blog stopped using Google fonts.
A single analytics loading script and the tracking payload is larger than the gains from the removal of these tags. Most pages have more than one script and payload too.
Firefox has a tracker blocking mode that shows you all of the trackers. I counted 25 different tracker services being blocked on a single news article yesterday.
<!-- Google Analytics -->
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r; i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g; m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
<!-- End Google Analytics -->
That's 455 bytes, even if you have an adblocker and don't load the external javascript. No amount of removing html, head, and body tags will overcome this.
This reminds me of a job I recently did for a company that had duplicate Google Analytics tags. I removed one thinking I was helping only to be yelled at when their numbers were cut in half the following month.
After I explained that they were getting incorrect information I was told "I know this isn't exactly ethical ..." yada yada. I fired that client.
Omitting tags is something we can get used to, but just by looking at the spec I'm kinda scratching my head.
Eg. why can't the closing tag for title be omitted? Tags are not allowed inside it.
I guess it's because you should be able to type tags as the title, but having to think about stuff like that makes ommiting more of a hassle than it's worth to me.
And what if templates are used and put together? Then you suddenly need to know how every combination of templates is going to be in the future to avoid unintended side effects.
Saving a bit of data on HTML isn't my top priority, and why would it? Just by not using a bunch of css/js-libs/fonts I'm able to have a smaller footprint than 99 percent of all pages.
115 comments
[ 3.5 ms ] story [ 191 ms ] threadSuperheroes.
https://news.ycombinator.com/newsguidelines.html
You're commented needed to modified for current times. ;-)
If this was truly the case, we wouldn't need things like Applitools to view our HTML documents in various browsers to scan for differences.
The example document in the HTML+ spec (1993) did not use them: https://www.w3.org/MarkUp/HTMLPlus/htmlplus_7.html
The HTML 2.0 spec gives this as its first example:
Certainly by the point of HTML 2.0 (November 1995; the first non-draft spec for HTML) all three elements have start and end tags all optional.
The more general ability to omit start/end tags from given elements is a feature of SGML (October 1986), and HTML 2.0 to HTML 4.01 were defined as SGML applications (though approximately nothing ever used an SGML parser for HTML).
Note though that there are some conditions.
They're seriously going to say that removing `<html></html>` is a file size optimization? Why does this make it easier to scan?
And for what - to save literally 10 bytes?
The savings from this won't be the slightest bit significant to them.
HTML has been deprecated in favor of Google Markup Language (GML).
And every web developer references the spec when they have questions...don't they?
For example, it keeps your indentation level flat here.
> For file size optimization and scannability purposes
Omitting tags means less transfered bytes means faster websites. If the browser can forgivingly parse HTML like this, why not take advantage of it?
Of course, it doesn't sit well with me either. This'll take some time to digest, but it is interesting to consider.
Perhaps HTML could have been better designed with performance in mind. Every tag you open (i.e. <foo>) you're supposed to close (i.e. </foo>) which is quite redundant in terms of bytes when you think about it. It is easy to imagine markup languages that minimize the number of bytes the client has to transfer.
Cutting out optional tags will improve page size, download speed etc; something that's obviously important when you're serving so many billions of users.
(Seems like a terrible idea to me - complex rules to follow for a really minimal saving...)
These days Im trying out pug instead, which is similar in a sense: more concise and readable at the expense of other people being certain of its correctness and myself remembering the syntax months later.
Sounds superstitious.
Anyway, parsing HTML is a nightmare, and HTML documents are usually broken in the wild, and browsers still, amazingly, manage to render almost anything you throw at them. I'm sure they all already handle it.
Maybe you haven't considered it closely enough?
If you look at the specifications, there is a complex set of rules governing the conditions under which a tag may be omitted. These naturally complicate the syntax. Consistency is preferable because it typically results in a simpler syntax.
Consider the following language:
It encodes a document like the following: i.e. a list of trees of tags named by symbols.Now, try to describe the language that's identical except that the closing bracket is optional if it belongs to a 'w' tag that precedes an 'x' tag. Try even to describe a language where they are not optional, but must be omitted. They'll both be more complex than the language I described above. Now imagine that there are about a hundred such exceptions, as in HTML. Chances are that rather than encoding them as syntax for the parser, you'll complicate the lexer to automagically insert the optional tags, fuzzying the boundary between the lexer and parser.
> Anyway, parsing HTML is a nightmare, and HTML documents are usually broken in the wild
Exactly because the syntax is needlessly complicated.
What is a machine supposed to do with the <html> tag? It's entirely useless and tells you nothing. At best it could be used to identify file type, but the doctype has long since replaced that usage and that still wouldn't justify any reason for the end tag.
Similarly for <head> and <body>. They don't really do anything. There's no machine-useful structure to be had from that.
For some of the optional end tags sure, that definitely helps make things easier for machines to understand. That's why XHTML exists. It's not really used, though, but if you really want easy to understand document structure for machines you wouldn't go anywhere close to HTML in the first place and instead use XHTML.
> This project (google/styleguide) links to the style guidelines we use for Google code. If you are modifying a project that originated at Google, you may be pointed to this page to see the style guides that apply to that project.
These are just Google's style guides for their own code. They're not saying you should do this in your own code.
---
>Are you referring to the group think that Google is full of evil hypocrites?
I'm confused, what are you trying to say?
I thought it was referring to the <main> tag.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ma...
Because if not, then by following Google's advice here we are creating the new Internet Explorer.
You can view source, and they post it to GitHub.
https://github.com/google/styleguide/blob/gh-pages/htmlcssgu...
I'm pretty sure you could remove all the head and body tags from the entire internet and it would still make less of a performance impact than if every WordPress blog stopped using Google fonts.
After I explained that they were getting incorrect information I was told "I know this isn't exactly ethical ..." yada yada. I fired that client.
But there's no reason to ignore literally free improvements just because there's bigger, not free improvements to be had as well.
Eg. why can't the closing tag for title be omitted? Tags are not allowed inside it.
I guess it's because you should be able to type tags as the title, but having to think about stuff like that makes ommiting more of a hassle than it's worth to me.
And what if templates are used and put together? Then you suddenly need to know how every combination of templates is going to be in the future to avoid unintended side effects.
Saving a bit of data on HTML isn't my top priority, and why would it? Just by not using a bunch of css/js-libs/fonts I'm able to have a smaller footprint than 99 percent of all pages.