Google Reveals its HTML, CSS and JavaScript Style Guides

Are you forced to adhere with company coding guidelines set in stone at some point in 1969? Or are your fellow developers free to express their artistic side with embedded ASCII art? I like browsing through style guidelines. There are usually obvious rules, those which seem bizarre and a few hidden gems which you hadn’t discovered before. Unfortunately, few companies are brave enough to publish internal guidelines. The BBC revealed their documents in 2010 but Google has finally released the style guides the company uses for internal projects. Rules are provided for C++, Objective C, Python, XML, and R — but we’re most interested in HTML, CSS and JavaScript. The documents are refreshingly short. I’ve seen too many where developers are expected to learn 1,001 arcane and subjective rules which show-off the writer’s knowledge rather than imparting useful advice. Let’s take a closer look…

HTML

There are few surprises in the HTML style guide:

serve semantic HTML5 as text/html
separate markup, styling and scripting
validate your markup when possible
use fall-backs when technologies such as canvas aren’t supported

Google recommends shaving every byte: files should be UTF-8 encoded, trailing white space should be trimmed and you should avoid entity references such as — and ”. They even recommend omitting optional structures and closing tags, e.g.


<!DOCTYPE html>
<title>Saving money, saving bytes</title>
<p>Qed.

Uggh. I’m all for saving a few bytes but still prefer a stricter XHTML-like syntax. Strangely, Google recommends indenting with two spaces rather than a tab. Isn’t that twice the quantity of whitespace characters you need?!

CSS

Stylesheet guidelines are dominated by further best-practice and byte-saving techniques:

use valid CSS unless dealing with bugs or proprietary syntaxes (vendor prefixes)
use short ID and class names, but ensure they’re not cryptic or presentational (e.g. #blue-button)
consider prefixed names for larger projects, e.g. #xyz-help, .xyz-column
simplify selectors when possible, e.g. #example rather than ul#example
use shorthand syntax notations
do not use quotes in url() or unit values after a zero
use short #abc hexadecimal color notation rather than #aabbcc
end every declaration with a semi-colon (even the last one)
avoid browser hacks

Google suggests omitting leading zeros from measurements, such as .5em. It saves a character, but I prefer code which is easier to scan. The guide recommends a newline for every comma-separated selector which applies to a block. I tend to agree, although I’m guilty of using long lists of selector strings. Finally, it states that property declarations should be alphabetized, e.g.


#example
{
	border: 1px solid #000;
	border-radius: 6px;
	display: block;
	font-family: sans-serif;
	margin: 1em;
	outline: 0;
	padding: 10px;
	text-align: center;
}

Personally, I prefer to order properties in related chunks, such as block type/dimensions, fonts, text alignment, padding, margins, color, background, border and miscellaneous properties. Perhaps it would confuse some developers but I’ve used the method for many years and works for me.

JavaScript

Understandably, the JavaScript style guide is longer but eases you in with the basics:

always use var to declare variables
always end lines with a semi-colon
use standard rather that non-standard features
use camelCaseNames and UPPERCASE constants, but avoid the const keyword which isn’t supported in IE
use namespacing techniques
avoid eval() except for deserialization (strangely, JSON.Parse isn’t mentioned as an alternative)
avoid with() on objects and for-in on arrays
use array and object literals rather than more verbose declarations
be aware of truthy and falsy rules
do not use IE conditional comments in your JavaScript source
don’t modify the prototypes of built-in objects — that’s a shame since it’s one of JavaScripts more powerful features, but you know it’ll lead to problems
use closures carefully and do not introduce circular references
similarly, be careful using ‘this’

There was one unusual recommendation: don’t use functions within blocks, i.e. write:


if (x) {
  var foo = function() {}
}

rather than:


if (x) {
  function foo() {}
}

You’ll see the second syntax used everywhere. It works without problems but it’s not valid ECMAScript. The document also mentions that wrapper objects should never be used for primitives unless you’re typecasting. It can lead to unexpected results such as:


var x = new Boolean(false);
if (x) {
	// this code evaluates
}

Dumb JavaScript. Finally, the guide states you should use single quotes (‘) in preference to double quotes (“) when delimiting strings which could contain HTML attributes. I use double quotes everywhere and I’m not sure I can change the habit easily. That said, I use single quotes for static PHP strings, so perhaps I’m being picky! The best advice is saved for the end of the documents: be consistent. Developers will rarely agree with every programming guideline but you should follow your own rules. It’ll make life easier for others trying to understand your code and when you when return to it six months later. Do you agree with Google’s Style Guides? Does your company force you to follow strange development practices?

Frequently Asked Questions (FAQs) about Google HTML, CSS, and JavaScript Style Guides

What are the key differences between Google’s HTML/CSS style guide and other style guides?

Google’s HTML/CSS style guide is unique in its emphasis on simplicity, readability, and efficiency. It encourages the use of simple, intuitive coding practices, such as using meaningful names for ID and class names, and avoiding the use of excessive nesting in CSS. It also promotes the use of comments to explain complex sections of code, and the use of whitespace for improved readability. These practices may differ from other style guides, which may have different priorities or coding philosophies.

How can I implement Google’s JavaScript style guide in my projects?

Implementing Google’s JavaScript style guide involves adhering to a set of coding conventions and best practices. These include using camelCase for identifier names, using single quotes for string literals, and placing opening braces at the end of the line. It also involves using JSDoc comments for all function declarations, and avoiding the use of global variables. To implement these practices, you can start by familiarizing yourself with the style guide, and then gradually incorporating its recommendations into your coding habits.

Why does Google recommend using HTML5 doctype?

Google recommends using the HTML5 doctype because it ensures that your web pages will be rendered in standards mode by all modern browsers. This means that your pages will be displayed consistently across different browsers, and will take advantage of the latest HTML features. The HTML5 doctype is also simpler and easier to remember than previous doctypes, which makes it more user-friendly for developers.

What are the benefits of following Google’s CSS style guide?

Following Google’s CSS style guide can lead to cleaner, more efficient code. The guide encourages the use of shorthand properties, which can reduce the size of your CSS and improve loading times. It also promotes the use of meaningful names for ID and class names, which can make your CSS easier to read and maintain. Additionally, the guide recommends organizing your CSS in a specific way, which can make it easier to navigate and understand.

How does Google’s HTML/CSS style guide handle responsive design?

Google’s HTML/CSS style guide encourages the use of responsive design techniques, such as media queries, to ensure that web pages look good on all devices. It recommends using relative units, like percentages or ems, instead of absolute units, like pixels, for sizing elements. This allows elements to scale proportionally when the viewport size changes. The guide also promotes the use of flexible images and grids, to create a layout that adapts to different screen sizes.

Why does Google’s JavaScript style guide discourage the use of global variables?

Global variables in JavaScript can lead to problems because they can be accessed and modified by any part of the code. This can make it difficult to track down bugs and can lead to unpredictable behavior. Google’s JavaScript style guide discourages the use of global variables to promote cleaner, more maintainable code. It recommends using local variables whenever possible, and using namespaces to group related functionality.

How can I validate my code against Google’s HTML/CSS style guide?

You can validate your code against Google’s HTML/CSS style guide by using a code linter, such as CSSLint or JSHint. These tools can automatically check your code for common errors and deviations from the style guide. You can also use online validators, such as the W3C Markup Validation Service, to check your HTML and CSS for syntax errors and compatibility issues.

What are the key principles behind Google’s HTML/CSS style guide?

The key principles behind Google’s HTML/CSS style guide are simplicity, readability, and efficiency. The guide encourages the use of simple, intuitive coding practices, such as using meaningful names for ID and class names, and avoiding the use of excessive nesting in CSS. It also promotes the use of comments to explain complex sections of code, and the use of whitespace for improved readability.

How does Google’s JavaScript style guide handle error handling?

Google’s JavaScript style guide encourages the use of exceptions for error handling. It recommends throwing an Error object, or a subclass of Error, when an error occurs, and using try/catch blocks to handle these errors. This approach allows for more robust error handling, as it provides more information about the error and allows for more precise control over how errors are handled.

Why does Google’s HTML/CSS style guide discourage the use of inline styles?

Inline styles in HTML can lead to code that is difficult to maintain and understand. They can also override styles defined in external CSS files, leading to unexpected results. Google’s HTML/CSS style guide discourages the use of inline styles in favor of external or internal CSS. This approach promotes cleaner, more modular code, and allows for better separation of concerns between HTML and CSS.