Google HTML/CSS Style Guide(google-styleguide.googlecode.com)
google-styleguide.googlecode.com
Google HTML/CSS Style Guide
http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml
11 comments
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.
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.
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.
It's unnecessarily limiting you to that one tag.
It's unnecessarily limiting you to that one tag.
I don't get this one:
Capitalization. Use only lowercase.
and:
Use HTML5. HTML5 (HTML syntax) is preferred for all HTML documents: <!DOCTYPE html>.
Why not <!doctype html>?
and:
Use HTML5. HTML5 (HTML syntax) is preferred for all HTML documents: <!DOCTYPE html>.
Why not <!doctype html>?
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.
They do.
CSS Formatting Rules > Selector and declaration separation
CSS Formatting Rules > Rule separation
CSS Formatting Rules > Selector and declaration separation
CSS Formatting Rules > Rule separation
The "Omit optional tags" section is rather... scary. Check out the example they include.
If you find it scary, you should really see this: http://paulirish.com/2011/primitives-html5-video/
I wonder why they suggest that? Their homepage is 115kb, so clearly they're not trying to absolutely minimize the size of their pages.
I wonder if the Chrome team had any input there.
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.
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.
Not closing <li>s is much easier to maintain. Look at my web page for instance, https://ajf.me/
It's not only easier, but more readable to do this:
It's not only easier, but more readable to do this:
<ul>
<li>Item 1
<li>Another item
<li>Yet another item
</ul>
<ul>
<li>Item 1</li>
<li>Another item</li>
<li>Yet another item</li>
</ul>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.
try loading that page with javascript disabled
Funny :)
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.
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.
> Do not use entity references
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...
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...
They save bytes. And as long as the UTF-8 rule is followed everything works fine. Also: editors that munge encodings without warning are evil.
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.
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.
Yeah, we worked a lot with outsourced development as well, and obviously didn't have any control over what tools they used...
Or even in some cases causing the encoding gremlins to get in.
I always have major problems with pretty quotes breaking when copying from GoogleDocs to Netbeans.
"That's how" becomes "That’s how"
I always have major problems with pretty quotes breaking when copying from GoogleDocs to Netbeans.
"That's how" becomes "That’s how"
And what about &'s in query strings?
I prefer tabs over spaces, the rest seem good
Luckily my text editor converts all your tabs to 2 spaces for readability and formatting working with multiple developers.
"Omit optional tags", but "Always use a single space between property and value ... for consistency reasons.". I'm confused.
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
<body>
The Maps API documentation here https://developers.google.com/maps/documentation/javascript/... still recommends it. Fortunately, they seem to have updated their maps API code samples to use something like this instead
google.maps.event.addDomListener(window, 'load', initialize);
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.
<body>
The Maps API documentation here https://developers.google.com/maps/documentation/javascript/... still recommends it. Fortunately, they seem to have updated their maps API code samples to use something like this instead
google.maps.event.addDomListener(window, 'load', initialize);
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.
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.