Leaving out the last semicolon of a CSS block

A couple of questions concerning this:

• Is it good practice?
• Will it, on a large scale, result in better load times?
• Can it result in browsers 'breaking'?
• Is the same true for the last function in JavaScript (/jQuery)?

What I mean is stuff like this:

#myElement {
  position: absolute;
  top: 0;
  left: 0
}

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

• No, leaving out that semicolon will introduce a great amount of risk in your application, it will be all too easy to overlook adding it back if you add more styles to your element. At that point, you are relying on your manual processes and attention to detail to ensure you didn't accidentially misplace on of your non-semicolon lines. Worse yet, you would have to physically check your css file every time you were ready to go to production to make sure you didn't screw up any of the final style lines in each element.

• Possibly, since the file would be smaller, but the difference should be negligible. If you are worried about load times, Gzipping your files before placing them on the server will serve you well.

• Most browsers are smart enough to know what you mean, but you still have to worry about screwing up your CSS file by not being careful about the last style.

• Is it good practice?

In my opinion, no. If you add a rule below the last rule, it's easy to forget to add the semicolon.

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

Can't imagine that it would make much of a difference in load time.

• Can it result in browsers 'breaking'?

No, semicolons are only required to separate rules in CSS blocks. Semicolons are delimiters, not terminators.

• Is the same true for the last function in Javascript (/jQuery)?

Yes, don't leave it up the JavaScript interpreter to add semicolons.

It will improve the loading time ever so slightly. With a large enough CSS file(s), it can even be noticeable (well, minification overall can be; I doubt just removing the final semicolon will ever be enough).

If you care that much about the loading times, however, you should be using a program to minify your CSS, not manually attempting to do it. Minified CSS is (all but) impossible to read. It's a bad practice to use this in the "source code" so to speak, because it's all too easy to forget it.

This is a duplicate question. See here:

https://stackoverflow.com/questions/2406717/semicolon-in-css

Regarding applying a semi-colon in JavaScript, functions should not end with semicolons unless they are assigned declaratively, viz. var a = function() {}; However, browsers perform automatic semi-colon insertion if you inadvertently (or purposely) leave them out.

Removing declaration stops will not "break" the browsers but should still be left for automated minifiers (especially if you're concerned with loading times - semicolons alone would not add up to much) but should be avoided in the source for maintainability reasons.

If you are looking for best practices, CSS formatting rules in the Google css styleguide is a very good place to start - not to blindly apply their suggestion but to see their reasoning behind it.

> Use a semicolon after every declaration. End every declaration with a > semicolon for consistency and extensibility reasons.

/* Not recommended */
.test {
  display: block;
  height: 100px
}
/* Recommended */
.test {
  display: block;
  height: 100px;
}

Javascript is a different story though - the short answer is always use semicolons, never rely on implicit insertion, but I've never seen an answer better and more thorough than as prescribed by Google in yet another styleguide of theirs:

> There are a couple places where missing semicolons are particularly > dangerous:

// 1.
MyClass.prototype.myMethod = function() {
  return 42;
}  // No semicolon here.

(function() {
  // Some initialization code wrapped in a function to create a scope for locals.
})();



var x = {
  'i': 1,
  'j': 2
}  // No semicolon here.

// 2.  Trying to do one thing on Internet Explorer and another on Firefox.
// I know you'd never write code like this, but throw me a bone.
[normalVersion, ffVersion][isIE]();



var THINGS_TO_EAT = [apples, oysters, sprayOnCheese]  // No semicolon here.

// 3. conditional execution a la bash
-1 == resultOfOperation() || die();

> So what happens? > > 1. JavaScript error - first the function returning 42 is called with the > second function as a parameter, then the number 42 is "called" > resulting in an error. > 2. You will most likely get a 'no such property in > undefined' error at runtime as it tries to call x[ffVersion][isIE](). > 3. die is called unless resultOfOperation() is NaN and THINGS_TO_EAT gets > assigned the result of die(). > > Why? > > JavaScript requires statements to end with a semicolon, except when it > thinks it can safely infer their existence. In each of these examples, > a function declaration or object or array literal is used inside a > statement. The closing brackets are not enough to signal the end of > the statement. Javascript never ends a statement if the next token is > an infix or bracket operator. > > This has really surprised people, so make sure your assignments end > with semicolons.

> Is it good practice?

I'd shy away from it as a smart minification process will handle this for you and it'd introduce errors if you forgot to place the semi-colon when adding new definitions.

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

Yes, smaller file size. Though, the difference is negligible and minification processes will automatically do this.

> Can it result in browsers 'breaking'?

No

> Is the same true for the last function in Javascript (/jQuery)?

No, it'd be "invalid" to exclude semi-colons at the end of a function statement.

Based on my experience, 1) It is not good practice 2) Even on a very large scale load times will be insignificant. 3) Not aware of any browser that would break from this. 4) Same true for jQuery

For CSS, I tried this out on IE9, FF, GC, Safari, and Opera, and it didn't make a difference.

As for Javascript, I got an error on FF and GC, so I would say don't do this on scripts. As for load time, the difference will not be in any way noticeable.