Introduction to CSS Minification

CSS minification as performed by this tool is not as complicated or in-depth as JavaScript minification. The CSS minification mostly consists of removing whitespace and most comments. Comments marked as “important” will always remain in the output, but depending on the settings used, certain comment-based hacks might also remain in the generated output.

Other small changes performed by the tool include reducing RGB values to their smallest possible length. For instance, rgb(255,128,0) would be changed to “#ff8000,” and “#ff9900” would be changed to “#f90.” Depending on the color-names setting, certain colors might also be changed to standard color names if they are shorter, or vice-versa. For instance, if strict (W3C-compliant) color names are to be used, “#ff0000” would get changed to “red.” There are also a larger set of color names that all major browsers recognize, but the use of which would produce invalid code when run through the W3C CSS validation tool. If the developer doesn’t care about generating invalid CSS (that still works in all major browsers), this setting can further reduce minified code.

Ideally a CSS minification tool would be able to analyze the rule set and eliminate redundant rules. This tool does not perform that kind of minification at this time.

Default CSS Minification

As mentioned in the introduction, the CSS minification portion of AjaxMin does not perform as sophisticated algorithms as the JavaScript portion. By default it will:

• Remove all insignificant whitespace.
• Remove all comments.
• Remove all unnecessary semicolon separators.
• Reduce color values.
• Reduce integer representations by removing leading and trailing zeros.
• Remove unit specifiers from numeric zero values.
• Utilize W3C-strict color names to further reduce resulting code.

CSS Minification Options

There are only a few CSS-specific command-line switches available in the Microsoft Ajax Minifier. Obviously, the –CSS switch to turn on the CSS Parser is one of them.

In order to specify how color names can be used in the resulting output, use the –COLORS switch. If the value of that switch is HEX (-COLORS:HEX), then no color names will be used, and the resulting RGB hexadecimal values will be substituted. If the STRICT value is used (default value), W3C-strict colors will be used if they are smaller than the hexadecimal representation. There are 17 colors recognized as W3C-strict: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, orange, purple, red, silver, teal, white, and yellow. If the MAJOR value is used, the color set is expanded to a well-known set supported by all major browsers. Code that uses these color names, however, will not validate as strict-compliant. The complete list of colors can be found online at a number of sites (there are a couple-hundred names with equivalent RGB values).

By default, all comments are removed. This behavior can be modified by specifying the –COMMENTS switch with one of three values. The default behavior is the NONE values (-COMMENTS:NONE). If all comments are to be preserved, use the ALL value, and if certain comment-based hacks are to be preserved, use the HACKS value.

If all rules need to be terminated with a semicolon, then specify the –TERM switch.

The only thing the –ANALYZE option will do is display a message indicating the amount of reduction the tool made in the sources, and how much further g-zipping on the server would produce.

The –ECHO option can be used to send the input unchanged to the output.

CSS Comment-Based Hacks

It has been very popular to use comment-based hacks to provide different CSS to different browsers without sniffing the user-agent string. It’s not a recommended practice, but it’s prevalent enough to warrant some attention by this tool. A number of popular hacks are preserved in the resulting code if the CssParser.CommentMode property is set to CssComment.Hacks. These hacks are (affected rules replaced with an ellipses): •Ignore rule for Internet Explorer for the Mac (discontinue product): comments that end with an escaped asterisk in the comment-terminator sequence continue on until the next unescaped terminator in MacIE. The result is used to hide rules from that browser:
/*(anything or nothing inside)\*/.../*(anything or nothing inside)*/

• A bug in Netscape 4 and Opera 5 allows a particular comment format to hide rules form all browsers except those:

/////.../(anything or nothing inside)*/

• A bug in Netscape 4 allows rules to be hidden from that browser:

///.../*(anything or nothing inside)*/

• A bug in IE6 can cause a property/value to be ignored if the property name is followed by at least one whitespace character and a comment before the colon:

property /*(anything or nothing inside)*/:value

• A bug in IE5.5 can be used to hide a property/value pair from that browser when a comment is between the colon and the value:

property:/* (anything or nothing inside) */value

• And finally, if we are preserving comment-based hacks, when the parser encounters an empty comment, it will assume it was put there as a comment-based hack and preserve it:

// or /* */

Important comments are always preserved, so one option for preserving comment-based hacks is to use that syntax: /*! (whatever) */. The exclamation point must immediately follow the opening asterisk. It will be removed in the resulting output, but the rest of the comment will remain.