Semicolon in CSS

Leaving out the last semicolon of a CSS block

Is it good practice?

It's not good practice to manually exclude semicolons. This is purely because it's easy to overlook when adding more styles, especially if you're working in a team:

Imagine you start with:

.foo {
    background-color: #F00;
    color: #000             <-- missing semi-colon
}

And then someone adds some styles:

.foo {
    background-color: #F00;
    color: #000             <-- missing semi-colon
    width: 30px;
    z-index: 100;
}

Suddenly the other developer is wasting time figuring out why their width declaration isn't working (or worse yet, doesn't notice that it's not working). It's safer to leave the semi-colons in.

Will it, on a large scale, result in better load times?

Most definitely, for every block, you'd save a couple of bytes. These add up, especially for large style sheets. Instead of worrying about these performance gains yourself, it's better to use a CSS compressor, such as the YUI Compressor to automatically remove the ending semi-colons for you.

Can it result in browsers 'breaking'?

No, it's safe, as browsers implement this part of the specification correctly. The CSS2 specification defines a declaration thusly:

A declaration is either empty or consists of a property name, followed by a colon (:), followed by a property value.

More importantly:

...multiple declarations for the same selector may be organized into semicolon (;) separated groups.

This means that ; is used to separate multiple declarations, but it is not needed to terminate them.

Is the same true for the last function in JavaScript?

JavaScript is a whole different beast with a completely different specification. This particular question has been answered in depth many times before on Stack Overflow.

Semicolon in CSS

True, it is not required, but I like to leave it in case I want to add any more attributes later. The page weight that it reduces by removing these is negligible.

Will CSS 3 still allow omitting final semicolons?

Looks like there currently is an ambiguity in the spec.

You correctly pointed out that 2. Syntax Description section prescribes ending every rule with a semicolon:

Each declaration has a property name, followed by a colon and the property value, and finished with a semicolon.

And at the same time, description of the parsing automaton in section 3.6.8. Declaration-value mode reads that a closing brace without a semicolon correctly ends a declaration and current rule at the same time:

} token

Append the current declaration to the value of the current rule. Pop the current rule from the stack of open rules, and append it to the value of the new current rule. Switch to the current rule's content mode.

So according to 3.6.8 trailing semicolon is optional.

I can't say about actual intention of the specification authors. But current situation should probably be reported and fixed. Most certainly they don't have intention of breaking the compatibility with CSS 2.1 and will reword their Syntax Description section in the final version.

Inline CSS formatting best practices - Two questions

Answer #1: No.

Semi-colons are required only between declarations.

A declaration-block (also called a
{}-block in the following text) starts
with a left curly brace ({) and ends
with the matching right curly brace
(}). In between there must be a list
of zero or more semicolon-separated
(;) declarations.

Source: http://www.w3.org/TR/css3-syntax/#rule-sets

The value of the style attribute must
match the syntax of the contents of a
CSS declaration block (excluding the
delimiting braces)

Source: http://www.w3.org/TR/css-style-attr/#syntax

Since you have only one declaration, there is nothing to separate, so no semicolons are needed.

However, the CSS syntax allows for empty declarations, which means that you can add leading and trailing semicolons as you like. For instance, this is valid CSS:

.foo { ;;;display:none;;;color:black;;; }

and is equivalent to this:

.foo { display:none;color:black }

---

Answer #2: No.

A declaration is either empty or
consists of a property, followed by a
colon (:), followed by a value. Around
each of these there may be whitespace.

Source: http://www.w3.org/TR/css3-syntax/#declarations

You can add spaces in order to improve readability, but they have no relevance.

Is there an explanation for why we cannot place semicolons between CSS declaration blocks?

In CSS, rules are defined by either blocks, or statements, but not both at the same time. A block is a chunk of code that is surrounded by a pair of curly braces. A statement is a chunk of code that ends with a semicolon.

An empty "rule" is not a valid CSS rule, because it cannot be parsed as either a qualified rule or an at-rule. So it stands to reason that a lone ; between two blocks is invalid, for the same reason that a block that doesn't contain a prelude (either a selector-list, or an at-keyword followed by an optional prelude) is invalid: because it cannot be parsed into anything meaningful.

Only at-rules may take the form of statements and therefore be terminated by a semicolon (examples include @charset and @import); qualified rules never do. So when a malformed rule is encountered, if the parser isn't already parsing an at-rule, then it is treated as a qualified rule and everything up to and including the next matching set of curly braces is consumed and discarded, including the semicolon. This is described succinctly in section 2.2 of css-syntax-3 (it says the text is non-normative, but that's only because the normative rules are defined in the grammar itself).

And the reason error handling takes such an eager approach in CSS is mostly due to selector error handling — if it were conservative, browsers might end up inadvertently parsing the following rule as something completely unexpected. For example, if IE6, which doesn't understand >, were to ignore just the p > in p > span {...} and regard everything starting with span as valid, the rule would end up matching any span element in IE6, whilst matching only the appropriate subset of elements in supporting browsers. (In fact, a similar issue does exist in IE6 with chained class selectors — .foo.bar is treated as .bar.) You could think of this, therefore, not as liberal error handling, but conservative application of CSS rules. Better not to apply a rule when in doubt than apply it with unexpected results.

Whoever told you it was for performance reasons is just making it up.

---

Related Topics