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.
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.
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,
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 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. ;)
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.
"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.
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.
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.
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?
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 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).
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.
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).
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 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.
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.
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.
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.
<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.
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.
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).
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.
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.
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.
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.
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'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).
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:
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.
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.
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.
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 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.
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.
> 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"
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.
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.
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.
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.
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:
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.
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:
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):
> 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):
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.
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.
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?
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.
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.
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>...)
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
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.
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! :)
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
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.
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.)
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).
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]
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.
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.
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].
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).
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.)
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.
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.
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.
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).
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
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).
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 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.
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.
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.
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.
Please don't post uncivil, unsubstantive comments to HN.
Also, please don't create many obscure throwaway accounts on HN. This forum is a community. Anonymity is fine, but users should have some consistent identity that other users can relate to. Otherwise we may as well have no usernames and no community, and that would be an entirely different forum.
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.
> 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?
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.
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.