I like almost all of these rules; however (as others have said), that "Omit optional tags" section is pretty risky to use in any serious project. I can see where Google wants to go with this recommendation, but I think that it will take a while for the majority of the web to get accustomed to this convention.
I find not closing my <li>s and many of my table tags (e.g. https://gist.github.com/1117438) lends to much more readable and maintainable markup. <head> and <body> I'd leave explicitly there, the tag autogeneration rules conflict with HTML5 elements in oldIE.
IMO, you shouldn't ever drop optional tags for a byte payload reason, this is what minifiers are for (htmlcompressor is extremely robust). But sometimes it makes sense to drop some closing tags so your source isn't an overgrown garden of angle brackets.
If your list is that simple, it takes no extra effort to add closing tags (especially if you're using a worthwhile IDE). If your list is more complicated, the closing tags will increase readability while decreasing ambiguity (and again they require no extra effort in a good IDE). This kind of thing might make sense for Google as a way to cut down on bandwidth costs over a long period of time, but it's a bad practice for 99% of the people reading it.
That's surprising. They've saved me many times when files are opened and re-saved in different editors, from losing an accent or an em-dash halfway down the page where it's rarely noticed...
The bytes are completely trivial, unless your entire document is a non-latin script.
And my point is that the UTF-8 rule is not always followed, because source code gets passed around via e-mail, copied from browsers, edited in a console, saved with Notepad, and so on. Ideally file content would only ever be touched by source code editors configured only to ever operate in UTF-8 mode, but in the real world with real development teams and new interns, that is an impossible thing to ask.
At my last job, I made sure all accented characters in source code were only ever written with entity references, and we went from having weekly problems with accents somewhere on the site, to almost never.
If that describes your development process, you have problems that entities won't correct. I think you maybe misunderstand the audience here: these are guidelines for Google's engineers. Honestly I think demanding (and assuming) that your developers use a toolchain that doesn't suck is a reasonable choice in that environment. It may not be in all shops.
Although the guide does mention "Separation of concerns", I've seen quite a few instances of markup that looks like the following across multiple Google API docs/sample code snippets
Probably a minor thing, but I've seen people, especially beginners, who pick up the former style (which is generally considered a bad practice) because they've seen it on places like the Google Maps API docs.
> Avoid qualifying ID and class names with type selectors.
Unless necessary (for example with helper classes), do not use element names in conjunction with IDs or classes.
I've never heard a decent explanation for why, with this one. Unless you're intentionally creating a rule which is broad in scope, adding the element name helps document a rule, giving somebody who is unfamiliar with this CSS some context on how the rule is used. Other than saving a scant few bytes here and there, I can't see what the benefit is.
Semantically, a meaningful class or id shouldn't always need to be qualified by the element type. There are certainly times when you'd want to, though, if the element type changes the meaning.
E.g., An e-commerce site that displays products in both the main content region and the sidebar. Product names use h1 tags in the main content region and h2 tags in the sidebar. Selectors like h1.product-title and h2.product-title have different meanings, and they're more efficient than the alternative selectors #main .product-title and #sidebar .product-title.
From a performance standpoint, qualifying class and id selectors by the element type is probably less efficient than not qualifying them, so doing it unnecessarily makes the selector longer and more difficult to maintain and decreases performance.
I personally never specify "div", but always specify anything non-div.
This just reminds me in my CSS, what declarations I can expect to come "by default" with the element. If it's a "span.x" then I know it has "display:inline" by default.
The only exception is that I generally don't specify with "h1", "h2", etc. because I'll want to be able to move those around in the HTML for SEO reasons, and not have to keep changing my CSS to go along.
The ID or class name should document the rule (or a comment). Ideally CSS rules should be broad in scope so they can be reused, and you're not rewriting rules for different elements.
But, it's not HTML document, it's XML. Otherwise I would gladly point out that they used UPPERCASE tags, they closed their tags and they did not omit a protocol in xsl.
Nice, I always wonder how other developers (like in bigger companies) style their code. I'm even gonna try to send this to a few outsourced developers I work with to see if we can improve that area, which is basically their aquiles kneel.
I like it how they don't even mention that css properties should one per line (as though it is assumed). I really don't like having to deal with single line css.
