66

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
}
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Bram Vanroy
  • 27,032
  • 24
  • 137
  • 239
  • 1
    i use this for only one reason: to minimize the css file ;-) – Glavić Aug 13 '12 at 17:55
  • Better loading time: Yes – Simon Arnold Aug 13 '12 at 17:55
  • 10
    for your second question, pretty sure that a good minifier will deal with the issue of load times, so you may as well write it with clear markup first. – Jeff Tratner Aug 13 '12 at 17:56
  • 3
    lets make it clear: use clear markup like Tratner told, and delete last semicolon before } in a minifier... – Glavić Aug 13 '12 at 17:58
  • Use a CSS compressor such as [YUI Compressor](http://developer.yahoo.com/yui/compressor/) to perform minification, and you wont have to think about better load times. – zzzzBov Aug 13 '12 at 17:58
  • 3
    I don't think there is any sense in leaving off the last semicolon unless you also compress the whole block into one line and get rid of all the white space. And unless you have thousands of css blocks in your file, saving 1 byte each is really not going to make a huge difference – MrOBrian Aug 13 '12 at 18:03
  • Most CSS is served compressed nowdays. Compressors work by recognizing and encoding patterns. With the semicolon, the last part of the block would be ";↲}↲", and would be one symbol. Without the semicolon, the last part of the block would be "↲}↲", and would still be one symbol. The point is that uncompressed, it's only 1 byte difference per block; compressed it is even less - theoretically as little as just 1 byte. – Zaz Apr 26 '15 at 22:14
  • It is preferred if you can post separate questions instead of combining your questions into one. That way, it helps the people answering your question and also others hunting for at least one of your questions. – double-beep Mar 24 '19 at 11:09
  • 2
    Related: *[Will CSS 3 still allow omitting final semicolons?](https://stackoverflow.com/questions/11062615)* – Peter Mortensen Nov 19 '19 at 12:38

9 Answers9

98

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
zzzzBov
  • 174,988
  • 54
  • 320
  • 367
  • 5
    Re: "AFAIK, all browsers support leaving off the last semi-colon in a block" semicolons are _delimiters_ for properties, not terminators. – steveax Aug 13 '12 at 18:08
  • 1
    @steveax, I couldn't speak for certainty at the time, because I hadn't found where it was listed in the spec. I'm about to add some more details including the link to that particular bit in the css specification. – zzzzBov Aug 13 '12 at 18:10
  • 2
    See: [Rule sets, declaration blocks, and selectors](http://www.w3.org/TR/CSS21/syndata.html#rule-sets): "A declaration block 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." – steveax Aug 13 '12 at 18:16
  • 2
    strangely enough, google calls them [*declaration stops*](http://stackoverflow.com/a/11948884/1081234) – Oleg Aug 14 '12 at 08:57
  • I wouldn't say it's not good practise. If the only reason you can come up with for not leaving it out of the final declaration is that you may forget to add one in if a new rule is added then that's a pretty shoddy excuse and rather lazy on the programmers part. – jezzipin Jan 09 '14 at 09:51
  • 2
    @jezzipin, I'm coming at this from the experience of working with various different teams with various levels of experience. Anything that makes it easier to write functional code tends to be good practice, anything that makes it harder to write functional code tends to be bad practice. – zzzzBov Jan 09 '14 at 14:23
  • I can say from current experience that leaving out the last semi-colon can cause problems when you have more than one person working on the same CSS. – siliconrockstar Jun 04 '15 at 17:39
12
  • 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.

Robert Greiner
  • 29,049
  • 9
  • 65
  • 85
  • 1
    +1 for Gzipping, even though I'd say that there are better solutions for compressing. `ob_gzhandler` for one. But your link is fine as well, thanks. – Bram Vanroy Aug 13 '12 at 20:05
4
  • 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.

HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
steveax
  • 17,527
  • 6
  • 44
  • 59
1

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.

KRyan
  • 7,308
  • 2
  • 40
  • 68
1

This is a duplicate question. See here:

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.

Community
  • 1
  • 1
Micah Henning
  • 2,125
  • 1
  • 18
  • 26
1

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.

Oleg
  • 24,465
  • 8
  • 61
  • 91
0

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.

Alex
  • 34,899
  • 5
  • 77
  • 90
  • -1 for saying this would be a good practice, even with the caveat about it always being followed. It wouldn't be. +1 for mentioning minification though. – KRyan Aug 13 '12 at 17:58
0

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

Serj Sagan
  • 28,927
  • 17
  • 154
  • 183
0

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.

RandomDuck.NET
  • 490
  • 5
  • 17