Are CSS Minifiers that combine elements destructive?

Question

I found this CSS minifier (http://www.lotterypost.com/css-compress.aspx). There is a section at the bottom of that page labelled "What does the CSS Compressor purposely NOT do?" There are four things, two of which I couldn't understand why they might be destructive:

Combining individual margin, padding, or border styles into a single property.

  margin-top: 10px; 
  margin-right: 0; 
  margin-bottom: 8px;
  margin-left: 30px;

Becomes

  margin: 10px 0 8px 30px;

And combining styles for the same element that are specified in different style blocks.

#element {
   margin: 0;
}

#element {
   color: #000000;
}

Becomes

#element {
   margin: 0;
   color: #000000;
}

I think CSSTidy does both of these. Is the web page above correct? Are there situations where these types of minification might be a problem?

Tericaterina

I won't describe them as "destructive" but read his notes "Reason Not Used" – Wyant

Yeah I don't think their destructive, usually I use the shorthand method by default. – Tehee

Answer 1

I'm the developer of the CSS Compressor that is the subject of this question (http://www.lotterypost.com/css-compress.aspx), so I'll elaborate with an example of how a compressor can break the CSS cascade if a tool aggressively re-writes it.

There are many ways of targeting elements in a style sheet, and because a CSS compressor does not have intimate knowledge of the page’s DOM structure, classes, ids, etc., there is no way for a compressor to know if an optimization that crosses bracketed definitions will break or not.

For example, a simple HTML structure:

<div class="normal centered">
    <p>Hello world.</p>
</div>

And some CSS:

div.normal p {
    margin: 10px 0 10px 0;
}

div.centered p {
    margin: 10px auto;
}

div.normal p {
    margin-bottom: 5px;
}

The uncompressed code would produce a centered paragraph with a 10px top margin and a 5px bottom margin.

If you run the CSS styles through the CSS Compressor, you'll get the following code, which maintains the order and cascade of the original uncompressed styles.

div.normal p{margin:10px 0}div.centered p{margin:10px auto}div.normal p{margin-bottom:5px}

Let's say you want to aggressively compress the styles further, by combining the margins of the two div.normal p definitions. They both have the exact same selector, and they appear to redundantly style the bottom margin.

There would be two ways to combine the margins: you can either combine the two margin definitions into the first (top) div.normal p style or combine them into the last (bottom) one. Let's try both ways.

If you combine the margins into the first (top) div.normal p style, you get this:

div.normal p{margin:10px 0 5px}div.centered p{margin:10px auto}

The result of combining the margins that way would result in the bottom margin being incorrectly set to 10px, because the "centered" class would override the bottom margin (because the "centered" style defintion now appears later in the cascade).

If you combine the margins into the last (bottom) div.normal p style, you get this:

div.centered p{margin:10px auto}div.normal p{margin:10px 0 5px}

The result of combining the margins that way would result in the paragraph no longer appearing as centered, because the bottom "p" definition would override the left and right margins of "auto" that are defined in the "centered" class.

So we can see that by combining style definitions that even have the exact same selector can cause some pretty bad problems.

Would you personally ever write code like this? Maybe or maybe not. Because of the various "weight" rules of the cascade, it is possible to fall into this type of code trap without ever realizing it.

Furthermore, given the fact that in today's Web pages, multiple CSS files are often combined into one file to hit the server with fewer downloads, it is easy to imagine the CSS Compressor royally screwing up the cascade by re-writing multiple style sheets (possibly written by different people) that are appended together into one file.

In fact, I wrote the CSS Compressor for this very scenario on my Web site, Lottery Post. Each Web page has many style sheets supporting various jQuery and other components, and the CSS Compressor is used to automatically compress all of those style sheets into one single download. All pages on the site have at least 10 different style sheets combined together, and most pages have more than that.

For example, if you look at the code behind the CSS Compressor page itself, you will find the main style sheet in the head that looks like this:

<link rel="stylesheet" href="http://lp.vg/css/d11019.0/j2HKnp0oKDOVoos8SA3Bpy3UHd7cAuftiXRBTKCt95r9plCnvTtBMU2BY2PoOQDEUlKCgDn83h16Tv4jbcCeZ(gupKbOQ9ko(TcspLAluwgBqrAjEhOyXvkhqHA(h5WFDypZDK2TIr(xEXVZtX7UANdFp6n1xfnxqIMR8awqGE)vrwUgY2hrCGNNTt1xV7R1LtCSfF46qdH1YQr2iA38r1SQjAgHze(9" />

The gobbledeegook in the URL is actually an encrypted string containing all the style sheets to combine on the server. The server compresses them and caches the result.

The space- and time-saving techniques on that one style sheet call include:

• Combining many style sheets into one file/download by simply appending them all together
• Compressing the combined style sheet using the CSS Compressor (without messing up the cascade!)
• Using a different domain name (lp.vg) for the style sheet download, which improves the browser's ability to download in parallel
• Using a very short domain name (lp.vg)
• GZip compression is applied to the style sheet on the Web server
• The version number of the style sheet is embedded into the URL (".../d11019.0/...") so that if any style is changed in any of the multiple style sheets, I can change the version number and the browser will never use the version it has cached. (Note that the version number should be part of the URL path, not in the query string, because some proxy servers do not look at the query string to determine if a page should be retrieved from cache.)

I hope this better explains things and is helpful to those looking to improve page performance!

-Todd

MORE INFO:

To add to the above, imagine if we take your color example, and combine style definitions with the same selectors.

Here are some uncompressed styles:

div.normal p {
    margin: 10px 0 10px 0;
}

div.centered p {
    margin: 10px auto;
    color: blue;
}

div.normal p {
    color: black;
}

The CSS Compressor produces the following output:

div.normal p{margin:10px 0}div.centered p{margin:10px auto;color:blue}div.normal p{color:#000}

If we were to apply aggressive combining of style definitions that have the same selector, we will get the following code.

Method 1, combining both into the first definition, would incorrectly make the text color blue:

div.normal p{margin:10px 0;color:#000}div.centered p{margin:10px auto;color:blue}

Method 2, combining both into the second definition, would incorrectly make the text left-aligned:

div.centered p{margin:10px auto;color:blue}div.normal p{margin:10px 0;color:#000}

The only time combining style definitions with the same selector is 100% error-free is when the definitions appear directly one after the other, but in every other case this technique risks corrupting the cascade of styles.

I couldn't imagine a case where any developer would write code in this manner (two style definitions with the exact same selector, one immediately after the other), so I concluded that the amount of effort required to code it, and the possibility of an additional point of failure in the compressor, was not worth it by a long-shot.

Frankly, I would be very concerned about a CSS compressor that combined styles from different definition blocks, because the cascade is a very fragile thing, and it is extremely easy to break the cascade.

Telestich

Great answer! I really could not wrap my head around it without this explanation. My use-case is almost identical, and I'll be avoiding CSS compressors with this optimization for the same reasons as you. – Tericaterina

Answer 2

The page has a section on 'reason not used' that describes why it doesn't do these two things.

And on top of that, I would assume it's not trying to do these things because it isn't a complete CSS parser/interpreter, and would start to bork stuff like CSS conditional blocks.

Brillatsavarin

I guess the reason I put up this question was that I didn't believe the author of that page that it might be dangerous. Can you give an example that might be tricky for either rule? – Tericaterina

Sure - a CSS rule in a conditional block, like a media query, and a CSS rule not in one can't be combined predictably. – Brillatsavarin

Answer 3

By 'destructive' I presume you mean 'the CSS does not work as expected'.

Combining long-hand rules such as your first example can be done without any ill effects at all.

In a plain old stylesheet with no media blocks or other fancy stuff, the second example will also not cause any problem.

The reason #2 is risky is because changing the order of rules, or folding rules together without taking the Cascade into account, can result in breakages.

Some CSS compressors can reorder rules alphabetically, or by selector type. These are very risky because moving rules around may break cascaded behavour the author created.

Minifiers like the YUI compressor don't do any of these, opting for safer strategies like removing whitespace, redundant semi-colons and zeros, and the like.

With more CSS containing media blocks and other CSS3 code it is likely that many of the current CSS compressors won't work correctly at all. Most do not have a proper lexer for parsing the code - they use context aware byte-by-byte (Tidy) or regexs (most of the rest) to process the code.

When selecting a compressor I would suggest finding something that will do it locally and is backed with good test suite so you can see what case are (and are not) handled correctly.

Oestrin