Google HTML/CSS Style Guide

http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml

by mmahemoff • 14 years ago

89 31 14 years ago

google-styleguide.googlecode.com

tobyjsullivan• 14 years ago

The "Omit optional tags" section is rather... scary. Check out the example they include.

rollypolly• 14 years ago

I wonder if the Chrome team had any input there.

whichdan• 14 years ago

I wonder why they suggest that? Their homepage is 115kb, so clearly they're not trying to absolutely minimize the size of their pages.

sebphfx• 14 years ago

It's valid HTML5 but I can't get used to not close list items and even the body.

rimantas• 14 years ago

It is also valid HTML4. If you are not comfortable not closing the body, you can just omit the opening tag also :). Likewise with html and head.

TazeTSchnitzel3• 14 years ago

If you find it scary, you should really see this: http://paulirish.com/2011/primitives-html5-video/

taylorlapeyre• 14 years ago

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.

paulirish• 14 years ago

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.

TazeTSchnitzel3• 14 years ago

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:

    <ul>
        <li>Item 1
        <li>Another item
        <li>Yet another item
    </ul>

Than this:

    <ul>
        <li>Item 1</li>
        <li>Another item</li>
        <li>Yet another item</li>
    </ul>

temp112• 14 years ago

try loading that page with javascript disabled

selectnull• 14 years ago

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.

crazygringo4• 14 years ago

> 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...

ajross2• 14 years ago

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.

crazygringo4• 14 years ago

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.

harisenbon• 14 years ago

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"

isleyaardvark2• 14 years ago

And what about &'s in query strings?

humbyvaldes• 14 years ago

I prefer tabs over spaces, the rest seem good

useful• 14 years ago

Luckily my text editor converts all your tabs to 2 spaces for readability and formatting working with multiple developers.

blago• 14 years ago

"Omit optional tags", but "Always use a single space between property and value ... for consistency reasons.". I'm confused.

rohitnair• 14 years ago

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

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.

mbylstra• 14 years ago

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.

TazeTSchnitzel3• 14 years ago

They do.

CSS Formatting Rules > Selector and declaration separation

CSS Formatting Rules > Rule separation

kapowaz• 14 years ago

> 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.

crazygringo4• 14 years ago

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.

isleyaardvark2• 14 years ago

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.

halefx2• 14 years ago

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.

Geenkaas• 14 years ago

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>?

pacomerh• 14 years ago

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.

Google HTML/CSS Style Guide

Related Stories