Google HTML/CSS Style Guide: Good Style or Bad Taste?

By Xah Lee. Date: . Last updated: .

Google now has a coding style guide for HTML/CSS, at http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml (Revision 2.2) (local archive: Google_html_css_style_guide_2012-07-30.txt)

latest version https://google.github.io/styleguide/htmlcssguide.xml

Here is a few interesting things.

Omitting Protocols in Links

Google suggests omitting protocols in links that are HTTP/HTTPS. Example:

<!-- No-->
<script src="http://www.example.com/main.js"></script>
<!-- Yes -->
<script src="//www.example.com/main.js"></script>

Google says:

Omitting the protocol—which makes the URL relative—prevents mixed content issues…

This is called protocol-relative URL Format. It prevents messages like «This Page Contains Both Secure and Non-Secure Items».

The problem with this is that, if your HTML is designed also for local browsing (such as HTML based book), such link won't work.

HTML5's Short charset Meta Tag

The charset meta tag can be shortened. Following is HTML4 syntax:

<!-- HTML 4 -->
<meta http-equiv="content-type" content="text/html; charset=utf-8" />

following can be used for HTML5:

<!-- allowed in HTML 5 -->
<meta charset="utf-8" />

By some quick web research, it appears that it's been said and tested from HTML5 folks that this shortened version always works, even in very old browsers. That's why HTML5 folks made it into HTML5 spec.

Note: it's a good practice to always include a charset declaration, and it should be utf-8.

HTML5: “type” Attribute for CSS/Javascript Not Necessary

in HTML5, “type” attribute can be omitted in the link to CSS or JavaScript. Example:

<!-- HTML 4 -->
<link rel="stylesheet" type="text/css" href="mystyle.css">
<!-- allowed in HTML 5 -->
<link rel="stylesheet" href="mystyle.css" />

HTML5: Omitting Start/End Tags

Lots start/end tags can be omitted in HTML5. Here's Google's example:

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

This is really the worse recommendation, and a lousy part of HTML5 spec, because it makes the language much more confusing and complex.

It would be much better to NEVER omit tags, so the syntax is simple and regular.

Once you encourage omitting tags, soon people will omit tags that shouldn't be omitted, introducing confusion and complexity.

If you read the HTML5 “living standard” document, you can see how complex and confusing it is.

[HTML Living Standard — Last Updated 3 May 2012 At http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#syntax-tag-omission ]

quote:

An html element's start tag may be omitted if the first thing inside the html element is not a comment.

An html element's end tag may be omitted if the html element is not immediately followed by a comment.

A head element's start tag may be omitted if the element is empty, or if the first thing inside the head element is a element.

A head element's end tag may be omitted if the head element is not immediately followed by a space character or a comment.

A body element's start tag may be omitted if the element is empty, or if the first thing inside the body element is not a space character or a comment, except if the first thing inside the body element is a script or style element. A body element's end tag may be omitted if the body element is not immediately followed by a comment.

An li element's end tag may be omitted if the li element is immediately followed by another li element or if there is no more content in the parent element.

A dt element's end tag may be omitted if the dt element is immediately followed by another dt element or a dd element.

A dd element's end tag may be omitted if the dd element is immediately followed by another dd element or a dt element, or if there is no more content in the parent element.

A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, dir, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, 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 not an a element.

An rt element's end tag may be omitted if the rt element is immediately followed by an rt or rp element, or if there is no more content in the parent element.

An rp element's end tag may be omitted if the rp element is immediately followed by an rt or rp element, or if there is no more content in the parent element.

An optgroup element's end tag may be omitted if the optgroup element is immediately followed by another optgroup element, or if there is no more content in the parent element.

An option element's end tag may be omitted if the option element is immediately followed by another option element, or if it is immediately followed by an optgroup element, or if there is no more content in the parent element.

A colgroup element's start tag may be omitted if the first thing inside the colgroup element is a col element, and if the element is not immediately preceded by another colgroup element whose end tag has been omitted. (It can't be omitted if the element is empty.)

A colgroup element's end tag may be omitted if the colgroup element is not immediately followed by a space character or a comment.

A thead element's end tag may be omitted if the thead element is immediately followed by a tbody or tfoot element.

A tbody element's start tag may be omitted if the first thing inside the tbody element is a tr element, and if the element is not immediately preceded by a tbody, thead, or tfoot element whose end tag has been omitted. (It can't be omitted if the element is empty.)

A tbody element's end tag may be omitted if the tbody element is immediately followed by a tbody or tfoot element, or if there is no more content in the parent element.

A tfoot element's end tag may be omitted if the tfoot element is immediately followed by a tbody element, or if there is no more content in the parent element.

A tr element's end tag may be omitted if the tr element is immediately followed by another tr element, or if there is no more content in the parent element.

A td element's end tag may be omitted if the td element is immediately followed by a td or th element, or if there is no more content in the parent element.

A th element's end tag may be omitted if the th element is immediately followed by a td or th element, or if there is no more content in the parent element.

However, a start tag must never be omitted if it has any attributes.

This applies to language design too. Basically, you want to reduce “multiple routes” as much as possible. Any inconvenience, such as typing it, can be automated by tools. The worse offender is unix shell utils. [see Unix Pipe as Functional Language]

html close all the tags cartoon

Good Style or Bad Taste?

Overall, i think half of their recommendations are flaky. Their style guides for {Python, JavaScript} are much better. (See: http://code.google.com/p/google-styleguide/.)

For the HTML/CSS style guide, it seems they are pushing arbitrary preference. The reason they gave are not cogent. They are more or less opinion only, with lots room for argument. In many cases, it's not consistent within itself. Examples:

• They suggest indenting by 2 spaces. This is really getting into trivial opinion. Also, indenting is really not necessary. If you indent the whole HTML document, it increases file size significantly. By recommending number of spaces to indent, it opens a can of worms: should one do indentation for the whole HTML file or just part of it? If just parts, when is it appropriate? And the classic: Why spaces and not tabs?

• They suggest all lowercase for HTML (for tag names, attribute name/values, etc.). This'd be great advice for XML, since it is case-sensitive, and XHTML element names are all lowercase. But elsewhere they often suggest readability. Note that CAP CASE for tags were the recommended style for HTML from about 1995 to 2005. It's more readable, because it distinguishes markup data from content data. Sure, i myself prefer lowercase, because it's easier to type and compatible with XML/XHTML (when you move code), and readability isn't a problem because of syntax highlighting in editors. Still, this point illustrates the erratic change of tech philosophy over the past decade.

• They recommend using HTML5, and recommend against using XHTML. Note that XML/XHTML was widely considered the future from about ~2000 to ~2005. The HTML5 people are rebels and want to overthrow strict validation and XML. Curiously, google's style guide itself is in XML!

What is HTML5? It's a flying-faak-in-your-face against a decade of what W3C told us about what HTML should or should not be. HTML5 was started by mostly Apple and Google, and in the beginning was sneered by W3C, but W3C finally lost the power struggle and accepted HTML5. (HTML5 Doctype, Validation, X-UA-Compatible, and Why Do I Hate Hackers)

• They recommend using valid HTML when possible. But as far as i know, Google has never encouraged valid HTML in their hundreds blogs and videos for webmasters, and of the billions of pages Google produced, i'm not aware of one that is valid HTML. Google also pushes invalid tags to the world. [see Google Pushes Invalid HTML to the World]

• They recommend not to use redundant 0. For example, font-size: .8em;. This is a bit strange. This is less readable and saves one byte, yet they DO recommend a space after the colon, and recommend to always use a semicolon even when not necessary.

• They recommend: “Avoiding unnecessary ancestor selectors is useful for performance reasons.”. The example they gave:

/* Not recommended */
ul#example {}
div.error {}
/* Recommended */
#example {}
.error {}

This will save you a few bytes, and a few microseconds. However, it's a major reduction of precision and correctness. What if some iframe widgets you use on your site also uses the same class name? Meanwhile, elsewhere Google recommend adding a prefix as namespace to decrease name clashing. So, the 2 advice conflict.

All the above points are rather trivial. After all, its merely about “style”. However, some stylistic issues are critical. On critical issues such as correctness and well-formedness, Google seems to side with irregularity and bad taste.

BUY ΣJS JavaScript in Depth