
Google HTML/CSS Style Guide - mmahemoff
http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml
======
taylorlapeyre
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
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.

~~~
TazeTSchnitzel
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>

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

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

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

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

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

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

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

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

~~~
crazygringo
Yeah, we worked a lot with outsourced development as well, and obviously
didn't have any control over what tools they used...

------
rohitnair
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 onload="initialize()">

The Maps API documentation here
[https://developers.google.com/maps/documentation/javascript/...](https://developers.google.com/maps/documentation/javascript/tutorial#LoadingMap)
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.

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

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

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

------
temp112
try loading that page with javascript disabled

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

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

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

~~~
TazeTSchnitzel
They do.

CSS Formatting Rules > Selector and declaration separation

CSS Formatting Rules > Rule separation

------
humbyvaldes
I prefer tabs over spaces, the rest seem good

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

