There is, of course, a little bit more to it than that. Under the hood, I’ve got a series of HTML5 Audio objects that are used to provide polyphonic audio using a simple round-robin algorithm (I encoded the audio in OGG, so you’ll need to use an OGG-friendly browser, like Firefox). The particles are much simpler than those in my previous canvas dalliance, in that they don’t swarm, and their motion is more linear.

View (and hear!) it live

Cool CSS features used:

• Columns (Gecko, Webkit, Presto)
• Web fonts (Gecko, Webkit, Presto, Trident)
• CSS gradients (Webkit)
• CSS transforms (Gecko, Webkit)
• Text shadow (Gecko, Webkit, Presto)
• Assorted CSS3 selectors and pseudo-selectors (Gecko, Webkit, Presto)

In case you’re wondering, Gecko is Firefox’s rendering engine, Webkit is Chrome & Safari, Presto is Opera, and Trident is Internet Explorer. Now you know. Tell your friends!

All in all, lots of fun stuff to play with.

Rendering bugs

Of course, the fun thing about playing with cutting edge features is that you get to find all sorts of bizarre glitches and rendering issues. Here are a few that I’ve noticed during development.

Missing letters (Presto)

Letters just seem to go missing randomly from words — “you” becomes “yo”, for example. I think that this is caused either wholly by the downloaded font, the use of columns, or a combination of the two. Quite annoying.

Pixel creep in columns (Webkit)

Every now and then, pixels from a word in column B will find their way to the very bottom of column A. It’s even worse when you set a box-shadow on an element — the top of the shadow is rendered in the previous column. I’m guessing that Webkit’s column-rendering algorithm basically renders the entire area in a long strip, then cuts it into chunks and shoves them on the page. Annoying.

Disappearing column rules (Gecko)

Apparently, setting the “overflow” property (or “overflow-x” or “overflow-y”) on an element that is rendered in columns prevents the column rule from being rendered in Gecko. I really have no idea why this should be the case — it’s a very strange behaviour.

HTML 5 element styling (Trident)

Internet Explorer can’t style elements that aren’t bog-standard HTML. Unless you use “document.createElement(‘elemName’)” on them first. Ridiculous.

There are quite a few CSS minifiers out there, which can bring the raw size of your CSS files down substantially. Very few of them, however, will also optimise your CSS for gzip compression. To that end, I’ve written a small Java application that will read in a CSS file and output its contents to stdout or another file in a format that’s optimised for gzipping.

The problem

A file will be most compressed when there are many recurring strings in the file. This means that when writing CSS files, this code:

.pony {
border: solid red 1px;
font-weight: bold;
}
.lemur {
border: solid red 1px;
font-weight: normal;
}

will be better-compressed than this:

.pony {
border: solid red 1px;
font-weight: bold;
}
.lemur {
font-weight: normal;
border: red solid 1px;
}

What it does

Specifically, my CSS minifier will perform the following transformations on the file:

• All comments are removed.
• The properties within all selectors are ordered alphabetically.
• The values for all properties are ordered alphabetically.
• All unnecessary whitespace is removed.

By way of example, the following CSS snippet:

body {
padding: 8px;
margin: 0;
background-color: blue;
color: white;
font-family: "Trebuchet MS", sans-serif;
}

h1 {
margin: 0;
padding: 0;
font-size: 200%;
color: #0F0;
font-weight: bold;
}

p {
margin: 0 0 2em;
line-height: 2em;
}

would be formatted to:

body{background-color:blue;color:white;font-family:"Trebuchet MS",sans-serif;margin:0;padding:8px;}h1{color:#0F0;font-size:200%;font-weight:bold;margin:0;padding:0;}p{line-height:2em;margin:0 0 2em;}

Compression results

A (very) large real-world CSS file of 78.2KB has a minified size of 63.7KB, which is a size decrease of nearly 20%. GZipping these two files, the un-minified file is reduced to 13.2KB, whilst the minified file weighs in at just 11.5KB — nearly 13% smaller.

Clearly, removing unnecessary whitespace and reordering the contents of the CSS selectors can greatly improve the compression of your CSS files, and thus make your pages deliver more quickly.

Comparison with YUI CSS Compression

As you can see in the chart below, the YUI compressor manages to make the original file around 1KB smaller than my minifier. However, when the two minified files are gzipped, my compression results in a file that is 11.5KB in size, whilst YUI only reduces down to 11.8KB.

Download

The source for this applet is available freely, and is a single Java file. It’s not particularly pretty, because I knocked this together in about half an hour.
Download
License: Mozilla Public License (In other words, do whatever you like with it. Credit is greatly appreciated, but not required.

Usage

First, if you haven’t done so yet, compile the code:

# javac CSSMin.java

Then, you can call the minifier by running

# java CSSMin in.css [out.css]

If you do not specify an output file, the resultant CSS will be printed to stdout (and can then be redirected as you wish).

Contact

If you have any questions or comments about this app, or if you find a bug or some weird behaviour, just comment on this post, and I’ll see what I can do.

If you find this utility useful, let me know! If you want to extend it, you’re free to do whatever you like with it, as it’s under the MPL. It would be nice, though, if you dropped me a line to let me know what you’re doing with it.

Future work

• Replace “0[px,em,%,etc]” with “0″.
• Replace “0 [0 [0 [0]]]” with “0″.
• Replace “0.6″ with “.6″ wherever possible.
• Replace all “rgb(64, 64, 64)” with “#404040″.
• Shorten colours from #112233 to #123 wherever possible.
• Remove all empty rules.
• Ordering of property valus according to the CSS spec, not just alphabetically.
• A cleaner interface, including the ability to stream and process from stdin.