17 ms·
Google HTML/CSS Style Guide – Omit Optional Tags
- hooph00p 10y agoI can get behind this.
- joekrie 10y agoThis blows my mind. Can't wait to bring this up in a code review.
- tangue 10y agoOk, 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.
- rimantas 10y agoThis was legal for ages. Why do people think this is HTML5 feature? This http://rimantas.com/bits/minimal_html.html http://rimantas.com/bits/minimal_html.html dates back to 2005, but of course it was possible well before that.
- TheRealPomax 10y agoSidenote: "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 https://pugjs.org
- Pxtl 10y agoAs 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.
- throwanem 10y agoIt 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.
- Sharlin 10y agoThat's a big part of what HTML 5 is about, to codify existing practice when it was realized that trying to push strict standards was fighting against windmills. Nobody would ever push their web pages to the browser as application/xhtml because the user getting a validation error instead of a working page due to any slight infraction would have been catastrophically poor UX. Thus, even "XHTML" pages were sent as text/html and parsed by browsers as tag soup - pretty much defeating the purpose of XHTML. Browsers accepting tag soup is just a manifestation of the Robustness Principle [1]: "Be conservative in what you send, be liberal in what you accept" [1] https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
- jpalomaki 10y agoWould 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?
- gsnedders 10y agoNot 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.
- emn13 10y agoIt 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).
- innatepirate 10y agoIn-spec or not, I don't like it
- keeganjw 10y agoHowever weird it feels, this makes sense. Why did we ever have do things like use an HTML tag immediately after declaring the DOCTYPE as HTML anyway?
- Sharlin 10y agoWell, the HTML tag is older than DOCTYPE. Andin SGML and, later, XML, the document must contain a single root element.
- gsnedders 10y agoThe 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.)
- TheRealPomax 10y agoBecause 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.
- mozumder 10y agoThe rules are really complicated here. It's best to do this using a minifier instead of through hand-coding.
- TheRealPomax 10y agoSounds 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.
- Diti 10y agoGoogle probably has their own minifier. The development of such a tool would need to have a specifications page ready. Such as that one.
- the_mitsuhiko 10y agoThat'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.
- tedmiston 10y agoDo you have a linter or some such automated style guide that you use to enforce this style?
- the_mitsuhiko 10y agoNot really but pretty sure that's the default serialization of html5lib.
- gsnedders 10y agoFor 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).
- dom96 10y agoHrm, is anybody else's browser not navigating to the "Optional Tags" anchor?
- deleted 10y ago[deleted]
- Kenji 10y agoUhh... I wonder how large the percentage of users is that see a broken site if you strictly adhere to that principle.
- Sharlin 10y agoBrowsers 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.
- fiddlerwoaroof 10y agoThis behavior is actually older than HTML itself is: https://en.wikipedia.org/wiki/Standard_Generalized_Markup_Language#Markup_minimization https://en.wikipedia.org/wiki/Standard_Generalized_Markup_La...
- Sharlin 10y agoYeah, true. SGML certainly has some "interesting" features.
- TheRealPomax 10y agoA 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.
- Kenji 10y agoI 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.
- kgtm 10y agoMaybe 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.
- userbinator 10y agobut I think in general it is a mistake to make developers think about when and where certain things can be omitted. Yes, sometimes it is better to make developers think about when and where certain things are required.
- nchelluri 10y agoI agree, but maybe a transformer step could do it automatically. Write full HTML, generate less.
- h1d 10y agoAfter 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...
- CoryG89 10y agoWhy 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.
- reimertz 10y agoscripts in <head> tag works perfectly as well as long as you position scripts above elements you would put in the <body> . I will start doing this! demo: http://jsbin.com/duqonahiyi/1/edit?html,console,output http://jsbin.com/duqonahiyi/1/edit?html,console,output
- nchelluri 10y agoYes, 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 https://developers.google.com/speed/docs/insights/BlockingJS
- tedmiston 10y agoJust to put the code sample here... <!-- Not recommended --> <!DOCTYPE html> <html> <head> <title>Spending money, spending bytes</title> </head> <body> <p>Sic.</p> </body> </html> <!-- Recommended --> <!DOCTYPE html> <title>Saving money, saving bytes</title> <p>Qed. Does the <head> tag really not matter anymore?
- Klathmon 10y agoI 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".
- Sidnicious 10y agoOne 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.
- tedmiston 10y agoI've been sleeping on best practices here... is it preferred to do a script with defer in the <head> over putting it at the bottom of the <body> now?
- angry-hacker 10y agoDoesn't matter much with defer or async. If you but the at the bottom, they start loading in parallel slightly later.
- franze 10y agohere is an edge case: the <head>-tag might be optional, but HTML elements do have a different behavior when placed in the <head> section or the <body> section. namely, the always beloved <noscript> tag https://developer.mozilla.org/en/docs/Web/HTML/Element/noscript 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>...)
- franze 10y agoreplying to myself like a pro: after reading the spec https://www.w3.org/TR/html5/scripting-1.html#the-noscript-element https://www.w3.org/TR/html5/scripting-1.html#the-noscript-el..., the <noscript> element is even trickier, it has at least 4 parsing modes: in the head with scripting disabled (no text, only link, style, meta) in the head, with scripting enabled (can include text (like whitespaces) but parsed elements must result in link,style,meta DOM only) in the body with scripting disabled (text, but no other noscript) in the body with scripting enabled (text, but no other noscript and script tags) so basically <html><noscript><link href="e.css"></noscript><title>hi</title><h1>ho</h1> would be find, as the <head> would close just before the <h1> (in scripting enabled and disabled case) but: <html><noscript> <link href="e.css"></noscript><title>hi</title><h1>ho</h1> would close the <head> in a scripting disabled case just before the <noscript>-tag and closes the <head> just before the <h1> in a scripting enabled case. this would explain the DOMParser.parseFromString() behaviour, as it's a scripting disabled case....
- zcorpan 10y agohttp://software.hixie.ch/utilities/js/live-dom-viewer/saved/4486 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/... In Chrome Canary 55.0.2866.0 the noscript element contains a text node and a link element. This matches the spec as far as I can tell; whitespace is allowed in noscript in head.
- ebbv 10y agoBoo. 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.
- rimantas 10y agoThis is and pretty much always was a part of HTML standards.
- detaro 10y agoWhat they recommend conforms to standards and should parse identically in all HTML5 parsers.
- ebbv 10y agoOh my god talk about nitpicking. Yes I realize it's allowed, it's still sloppy and gross. Technically I could put all my HTML into base64 encoded strings in javascript and then write them to the document, that doesn't mean that I should.
- detaro 10y agoSorry, I seem to have misinterpreted the background of your initial comment (less human aspect, more browser parsing issues). It's certainly something you should either do automatically or in a consistent style, not as an excuse to leave out random things if you feel like it.
- anjbe 10y ago> 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?
- sanketsaurav 10y agoIt 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.
- mbrock 10y agoI 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.
- niftich 10y agoI 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?
- rimantas 10y agoIt is not new in HTML 5. You could omit a lot and have perfectly valid HTML 4.01 Strict too.
- bjt 10y agoThe 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.
- hannob 10y agoCompression 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.
- dunham 10y agoBut 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.
- LethargicStud 10y agoOne 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?
- franze 10y agoI agree, the protocol part seems pretty outdated.
- superchink 10y agoI think you're right. http://www.paulirish.com/2010/the-protocol-relative-url/ 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.
- nicoritschel 10y agoMy best guess would be that any work done by a Googler will be served up from a domain included in the HSTS Preload List (forces SSL in most browsers)
- TheAceOfHearts 10y agoI always omit the protocol because I develop on a local server using HTTP, but deploy to a remote server using HTTPS.
- mschuster91 10y agoIt's a screenscraping protection, too. Documents malformed this way cannot be parsed e.g. with PHP's DOM functions without significant headache.
- DasIch 10y agoThese 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.
- TheRealPomax 10y agoYou 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.
- jap 10y agoI've been omitting optional tags for a while. One thing I've noticed is that bing webmaster tools will report "The title is missing in the head section of the page" when there is a title, but no <head>. Maybe bing can't properly crawl pages without a <head>. Another service I've used had the same problem, but can't remember which. So it might be worth being careful with omitting <head> - and maybe other tags, I'm reconsidering whether it's a good idea.
- fresheyeball 10y agoThe Google HTML Styleguide people, really should inform google.com that they are bloated.
- fresheyeball 10y agoThe Google HTML Styleguide people, really should inform google.com that they are bloated.
- danjoc 10y agoWhy 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.
- bryanph_ 10y agoFor the love of god, can we please move on to more pressing matters.
- franze 10y agoThe Google JS Style Guide maybe? https://google.github.io/styleguide/javascriptguide.xml https://google.github.io/styleguide/javascriptguide.xml
- dubcanada 10y agoThe 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.
- progx 10y agoYear 2016: 4.5 G Networks rising, Smartphones with 1440P Screens are normal and many pictures and videos distributed in 4K resolution. And you really think about minification of html, js, or css to save some bytes?
- kalleboo 10y agoI just wish we had bigger MTUs to fit our bandwidth so we could reduce latency...
- Tepix 10y agoBigger MTUs would increase latency but also increase throughput.
- idreyn 10y agoWell Google might, if they serve those bytes a trillion times per year.
- progx 10y agogoogle did not serve them (ok from cache), google must read them and process the content, that cost google time and money.
- TheRealPomax 10y agoYou 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.
- zwetan 10y agoTo me this just prove that wether a spec or standard is in place. it does not really matter. In this case we have the weight of Google that says "oh it's in the spec so we can do it". In other case we have a standard like E4X, that everyone happily not implemented (Chrome) or removed (Firefox). They could as well say "If we don't like it we will not do it, if we like it we will do it", that would be exactly the same.
- TheRealPomax 10y agoalmost. 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.
- chriscareycode 10y agoA good video from Paul Irish on the subject http://www.paulirish.com/2011/primitives-html5-video/ http://www.paulirish.com/2011/primitives-html5-video/
- deleted 10y ago[deleted]
- kalleboo 10y agoWeb technologies are totally not piles of hacks on top of other hacks
- PaulHoule 10y agoIs 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.
- EdSharkey 10y agoHere'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.
- phil248 10y agoHell, I'mm still convincing people to use <br> instead of <br/>!
- yladiz 10y agoLike 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.
- mbrock 10y agoI've been omitting needless tags since HTML5 became a thing and I'm totally over any residual "weird feelings" from the XHTML days.
- markdown 10y ago> Sure, for really slow networks, e.g. in developing countries, it might matter, #thirdworldproblems, eh? There are more third-worlders than there are visually impaired people. Do you also disregard the blind?
- elmigranto 10y ago> 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… :)
- isaac739 10y agoGoogle's parent company is still using <head> and <body> tags. https://abc.xyz https://abc.xyz
- SimeVidas 10y agoWebsites 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
- draw_down 10y agoNot 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?!
- themartorana 10y agoGrammar 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.
- z3t4 10y agocant 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).
- ilaksh 10y agoVery cool. I did not know that stuff was optional. If its less code to type and send over the network then that's great. HTML 5 is not XML. Which is fine.
- snarfy 10y ago>Indentation >Indent by 2 spaces at a time. >Don’t use tabs or mix tabs and spaces for indentation. Let the wars begin.
- paradite 10y agoI can imagine many html crawlers and parsers breaking for these pages, searching for <head> or <body> but nothing to be found...
- emn13 10y agoWell, 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.
- ishener 10y agowhat's this style guide even mean when google.com doesn't adhere to it?
- n-gauge 10y agoThis to me is like: if (x) { ... ... } someMethod() Changed to : if (x) { ... ... someMethod() It's not as readable. Maybe as others have suggested, leave it to a compiler.
- anjbe 10y agoThe difference is that your example is ambiguous. “<p>Paragraph 1<p>Paragraph 2” is not ambigous, and never has been.
- kazinator 10y agoYou won't see this in too many C style guides: Emit all optional parentheses in expressions, unnecessary "break;" statements at the end of a switch, the type specifier keyword "int" when "unsigned" is already present in the declaration and other such fluff. I've done plenty of web scraping in which it was helpful to look for the <body> element.
- original_idea 10y agoThis is going to wreck havoc on XPATH selectors across the world.
- mbrock 10y agoXPath can't run on HTML5, you have to parse it into DOM first, so there's no problem.
- j4_james 10y agoHTML5 does actually support an XHTML serialisation[1] if you need your content to be easily parsed with XML tools. [1] https://www.w3.org/TR/html5/the-xhtml-syntax.html https://www.w3.org/TR/html5/the-xhtml-syntax.html
- mbrock 10y agoAh, yeah, indeed, thanks for the clarification.
- gsnedders 10y agoXPath 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).
- gsnedders 10y agoWhy? The elements are still there in the DOM and presumably in an XML infoset you create from the DOM produced from the HTML parser.
- sootzoo 10y agoIt's worth pointing out that this style rule itself is optional, which is to say they're not making a recommendation here, just providing an example of what applying the rule would look like. It carries the same weight as, say, the optional rule about grouping CSS sections and including a section comment[1]. [1] https://google.github.io/styleguide/htmlcssguide.xml?showone=Section_Comments#Section_Comments https://google.github.io/styleguide/htmlcssguide.xml?showone...
- spdustin 10y agoThe 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).
- emn13 10y agoIt'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.
- yuhong 10y agoI think Acid2 was partly responsible for this. See https://hsivonen.fi/last-html-quirk/ https://hsivonen.fi/last-html-quirk/
- sheriffderek 10y agoWhile 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! :)
- scrollaway 10y agoYes, think about all those bytes we could save by not sending doctype as uppercase! In XML, it's required uppercase. Unlike HTML being lax on tag structure, there is no reason to advise DOCTYPE to be lowercase. It's not "better".
- sheriffderek 10y agoI'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 https://www.youtube.com/watch?v=U-9tAqdd_4Y
- wanda 10y agoCapital letters for the word 'doctype' are not mandatory for HTML, only for XHTML. https://html.spec.whatwg.org/multipage/syntax.html#the-doctype https://html.spec.whatwg.org/multipage/syntax.html#the-docty...
- johndoe4589 10y agoInterestingly they don't seem to have a rule against one line declarations. I alwats use this style, which imho is very handy, because of the tree structure and admittedly because I have a super cool macro in Vim that copies the characters from the line above, word by word so create rules that afect children of the rule above it requires just a few keystrokes: #some-div { margin:1em 0; } #some-div .inner { padding:5px 10px; } #some-div .inner p { font-size:90%; } This makes the structure of the declarations more obvious imho, and I tend to have a nicely organized series of structures like that that are logically grouped together. Obviously this applies more to components/widgets than the basic rules and layout. If a declaration is long then I use newlines.. but even then I tend to group things together eg. #some-div { display:inline; margin: ...; padding: ...; border-radius: ...; border-color: ...; font-size:90%; text-align:center; } Basically within a css rule I'll group together the layout properties, the text properties, etc.
- teach 10y agoI'm very interested in that vim macro.
- johndoe4589 10y agoSure. This is one of the most useful macros I found online :) I'd love to link to the original page but I can't remember where it is from. Here it is: " Piece-wise copying of the line above the current one :imap <C-L> @@@<ESC>hhkywjl?@@@<CR>P/@@@<CR>3s
- ebbv 10y agoThe 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.
- simple10 10y agoHere's the direct github link if you want to fork or star: https://github.com/google/styleguide/blob/gh-pages/htmlcssguide.xml https://github.com/google/styleguide/blob/gh-pages/htmlcssgu...
- moron4hire 10y agoIn 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.
- ommunist 10y ago[3] Popular web frameworks will suffer.
- johndoe4589 10y agohttps://google.github.io/styleguide/htmlcssguide.xml?showone=Property_Name_Stops#Property_Name_Stops https://google.github.io/styleguide/htmlcssguide.xml?showone... How is adding a space after ":" any more consistent than having none? No space between property and value is more unique and searchable should you need to find something or do search/replace.
- detaro 10y agoThey 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).
- Animats 10y agoThis is one Google ad. Any questions? <h3><a style="display:none" href="http://www.googleadservices.com/pagead/aclk?sa=L&ai=DChcSEwi36oSzi5fPAhWBh34KHQO2A0YYABAF&ohost=www.google.com&cid=CAASJORo9LOCMjoibKPv7gF6cak7OxiE3TtM_tpkLykYWNps5wdfUw&sig=AOD64_3sHUU366i6dStUuQ_sGYCNCCiv9A&q=&ved=0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQ0QwIJQ&adurl=" id="s0p2c0"></a><a href="https://www.capitalone.com/credit-cards/compare/?external_id=WWW_VI194_ZZZ_ONL-SE_ZZZGO_T_SEM2_ZZZZ_c_Zg_" id="vs0p2c0" onmousedown="return google.arwt(this)" data-preconnect-urls="http://www.capitalone.com/,http://5138.xg4ken.com/" jsl="$t t-zxXzjt1d4B0;$x 0;" class="r-ifxiYWNp1hrU">Capital One® Card Offers - Apply for Credit Card Offers Now</a></h3> <div class="ads-visurl"> <span class="_mB">Ad</span><cite class="_WGk">www.capitalone.com/ApplyFor<b>Card</b>Offers</cite> <g-bubble class="action-menu ab_ctl r-iS1b0Exw3vQ8" jsl="$t t-R7dwiTmE0C4;$x 0;"> <a href="javascript:void(0)" data-theme="0" data-width="230" class="g-bbll" aria-haspopup="true" role="button" jsaction="r.saTe4DDW138" data-rtid="iS1b0Exw3vQ8" jsl="$x 1;" data-ved="0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQJwgm"><span class="mn-dwn-arw"></span></a> <div class="g-bblc" data-ved="0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQKAgn"> <div class="_lBb"> <div>This ad is based on your current search terms.</div> <div class="_zFc r-ivNjifPqiifI" jsl="$t t-h6cwAtrxkFI$t-wWNthJIwnKo;$x 0;">Visit Google’s <a href="javascript:void();" jsaction="r.8Na6VOGeTa8" data-rtid="ivNjifPqiifI" jsl="$x 7;" data-ved="0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQKQgo">Why This Ad page</a> to learn more or opt out.</div> </div> </div> </g-bubble> </div> <div class="ellip ads-creative">Find Great Rates & Rewards—Apply.</div> <div class="ellip">Autopay · Online Banking · Account Alerts · Travel Benefits · Security Alerts</div> <div class="ellip">Services: Apple Pay™, Chip Technology, Second Look®, Image Card℠, Wallet App</div> <ul class="_MEc"> <li><a style="display:none" href="http://www.googleadservices.com/pagead/aclk?sa=L&ai=DChcSEwi36oSzi5fPAhWBh34KHQO2A0YYABAG&ohost=www.google.com&cid=CAASJORo9LOCMjoibKPv7gF6cak7OxiE3TtM_tpkLykYWNps5wdfUw&sig=AOD64_0_5WQ5HIxnRdQEOpUEmdSkkiWV4w&ctype=4&q=&ved=0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQpigILCgA&adurl=" id="ads-0-0-2-1-0"></a><a href="https://findmycard.capitalone.com/?external_id=%7B_externalid%7D" id="vads-0-0-2-1-0" onmousedown="return google.arwt(this)">Find the Right Card</a></li> <li><a style="display:none" href="http://www.googleadservices.com/pagead/aclk?sa=L&ai=DChcSEwi36oSzi5fPAhWBh34KHQO2A0YYABAH&ohost=www.google.com&cid=CAASJORo9LOCMjoibKPv7gF6cak7OxiE3TtM_tpkLykYWNps5wdfUw&sig=AOD64_2iwTNF-VPyK96RTweJ4TAggXM4pw&ctype=4&q=&ved=0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQpigILSgB&adurl=" id="ads-0-0-2-1-1"></a><a href="http://www.capitalone.com/credit-cards/compare/?filter=nofee&external_id=%7B_externalid%7D" id="vads-0-0-2-1-1" onmousedown="return google.arwt(this)">Cards with $0 AMF</a></li> <li><a style="display:none" href="http://www.googleadservices.com/pagead/aclk?sa=L&ai=DChcSEwi36oSzi5fPAhWBh34KHQO2A0YYABAI&ohost=www.google.com&cid=CAASJORo9LOCMjoibKPv7gF6cak7OxiE3TtM_tpkLykYWNps5wdfUw&sig=AOD64_1AOh7CWEmBWXjNLs4Oondpyt-JAg&ctype=4&q=&ved=0ahUKEwiswYGzi5fPAhVSVWMKHYoQDjQQpigILigC&adurl=" id="ads-0-0-2-1-2"></a><a href="http://www.capitalone.com/credit-cards/compare/?filter=popular&external_id=%7B_externalid%7D" id="vads-0-0-2-1-2" onmousedown="return google.arwt(this)">See Popular Cards</a></li> </ul>
- asifnawaz562 10y agovcv
- asifnawaz562 10y agocxc
- asifnawaz562 10y agozz
- asifnawaz562 10y agonice
- deleted 10y ago[deleted]
- masswerk 10y agoSlightly amusing: HTML4, XHTML: Make sure to include all optional tags, because scannability. Now: For (...) scannability purposes, consider omitting optional tags.
- anjbe 10y agoHTML 4 didn’t require optional tags either. That culture was limited to XHTML.
- andrewclunn 10y agoThis 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.
- markdown 10y ago> I've never actually seen anyone validate their HTML. You must be new to this. Not only was it commonplace to do, we showed it off with fancy badges. This was especially important when you weren't writing all your own markup eg: CMS's (Joomla/Drupal, etc) with a template and half a dozen different plugins/extensions outputting html soup.
- icedchai 10y agoYeah, I'm very new to this. I've been doing web development since 1995. eye roll I have seen it done, but not in commercial environments I have worked. Pick a random web site and try validating it. Almost no sites validate without errors or warnings. That's how "important" it is.
- TSfFma7Zkw9p6vs 10y agoOh good. In addition to an interesting technical discussion, I was really hoping to witness a prick waving contest. Thanks for providing both.
- dang 10y agoPlease 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.
- dang 10y agoPersonal swipes spoil discussion. Both of you did this, so we detached the subthread from https://news.ycombinator.com/item?id=12522069 https://news.ycombinator.com/item?id=12522069 and marked it off-topic.
- icedchai 10y agoI apologize, it will not happen again.
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- huntermeyer 10y agoThis is really going to bother me: Use double ("") rather than single quotation marks ('') around attribute values
- ben_jones 10y agoHonest 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.
- zbjornson 10y agoI'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.)
- ClayFerguson 10y agoOmitting 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.
- parr0t 10y agoI'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.
- __derek__ 10y agoIt'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).
- parr0t 10y agoThat's really interesting, first I have heard about automated tools to validate code. Are there public tools out there you can use prior to commits for this purpose or are they generally done in-house?
- __derek__ 10y agoThe big one for Git is Overcommit[1]. The tools that it runs depend on the language, though. Some are community-driven[2], while others are baked into the language.[3] [1]: https://github.com/brigade/overcommit https://github.com/brigade/overcommit [2]: E.g., flake8 for Python: https://pypi.python.org/pypi/flake8 https://pypi.python.org/pypi/flake8 [3]: E.g., gofmt for Go: https://golang.org/cmd/gofmt/ https://golang.org/cmd/gofmt/
- imdsm 10y agoPerhaps 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.
- ommunist 10y agoI 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.
- aclsid 10y agoThis all good and nice for Google saving a few bytes, but how on earth are you supposed to specify page language with this scheme for instance.
- nathan_long 10y agoThis is bad advice for the vast majority of sites. It's like, "morbidly obese? Lose weight by not licking stamps!" Omitting `<head></head>` saves 13 bytes, assuming gzip didn't help in the first place. The average page weighs thousands of bytes, according to https://www.sitepoint.com/average-page-weight-increased-another-16-2015/ https://www.sitepoint.com/average-page-weight-increased-anot...). If your pages are like the average, you've already wasted too much time thinking about this. Go optimize your images, use less JS, and make 200 other size optimizations first. You'll probably never get around to this one.
- SZJX 10y agoWith 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.