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
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"
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.
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.
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).
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.
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.
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.)
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.
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.
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).
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.
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.
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.
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.
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).
<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!.
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.
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 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.
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).
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.
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.
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.
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.
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,
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.
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.
ok, so now part of the "data" is another "template" that must further process "data" based on "whatever the code is that the client needs to receive".
oh, your templates and build tools don't work that way, and you're not willing to work to support them? let the indian devs try a full system rewrite in java. That's what they're for.
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.
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. ;)
"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.
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
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?
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.
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?
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
302 comments
[ 4.2 ms ] story [ 270 ms ] threadBrowsers 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
(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.)
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.
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).
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.
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?
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.
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).
https://en.wikipedia.org/wiki/Standard_Generalized_Markup_La...
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.
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.
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.
Yes, sometimes it is better to make developers think about when and where certain things are required.
Frankly I'm amazed the HTML way of verbose writing still stands after all these years in a fast paced industry.
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
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.
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.
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.
> 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
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)
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.
Many React/Webpack flows do something like this (minify or use a barebones template HTML).
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.
Alternatively, don't use HTML at all. Use pug (formerly "jade") or something and now you're free from all those inconvenient angle brackets.
This is minification, isn't it?
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.
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.
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.
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 would have a better day to let webmasters know to use gzip if they aren't.
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.
(which, IIRC, was the original rationale behind that style guide rule)
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.
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.
oh, your templates and build tools don't work that way, and you're not willing to work to support them? let the indian devs try a full system rewrite in java. That's what they're for.
[1] https://www.w3.org/TR/html5/syntax.html#obsolete-permitted-d... [2] https://www.w3.org/TR/html5/infrastructure.html#namespaces
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.
But mostly I meant that you don't have to close the autoclosing tags.
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#...
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 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.
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."
demo: http://jsbin.com/duqonahiyi/1/edit?html,console,output
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".
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.
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.
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:
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...
Think of <HTML>, <head> and <body> as implied rather than missing.
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.
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.
Although I like to make <body> explicit to avoid ambiguity in case of <script> tags.
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.
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.
And this mode on VoiceOver up until 10 years ago was the default.
In the Windows world, yes, you're totally right.
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>...)
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
would be find, as the <head> would close just before the <h1> (in scripting enabled and disabled case)but:
would close the <head> in a scripting disabled case just before the <noscript>-tagand 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....
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.
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.
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.
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?
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.
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?
Code is read many more times than it's written. Removing unnecessary noise makes it easier to read.
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.
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.
Documents malformed this way cannot be parsed e.g. with PHP's DOM functions without significant headache.
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.
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.
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.
And you really think about minification of html, js, or css to save some bytes?
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.