Bite-sized CSS & HTML nuggets

Unprefix express in full swing

The big vendor prefix discussion comes and goes in waves, but one conclusion that always pops up is that these prefixes should have a shorter lifespan. Of course browser makers may shift the responsability to specification writers, arguing that specs take too long to reach Candidate Recommendation (CR) status. Well, it seems the unprefix express is finally picking up steam.

A few weeks ago we heard about unprefixed transitions, transforms, animations, gradients, IndexedDB (and more) in the next Internet Explorer, and this week the Firefox team anounced exactly the same.

This is all great news. Even better, as Lea Verou noticed:

Keep in mind that this means you don’t have to use the -ms- prefix at all for transitions, animations and gradients, since no stable build of IE was ever released that requires it.

Angles in gradients subject to change

Vendor prefixes have always been the subject of heated debates among web developers and designers. And although it’s easy to forget, a prefix basically means: this stuff is not finished, and might change in the future – use at you own peril.

A prime example of this recently cropped up concerning angles in CSS gradients. A few months back Fantasai posed a simple question to the web community: do you prefer the current way of defining angles (0 is east, continue counter-clockwise) or should we adapt a system of bearing angles, where 0 is north and we move clockwise? The response largely pointed in the direction of the latter option, and recent versions of the spec now read like this:

0deg points upwards, 90deg points toward the right, and positive angles go clockwise

It’s great to see that the people writing the specs actively listen to feedback from the community, but this means that browsers will have to implement this backwards-incompatible change sooner or later. So yes, CSS gradients defined with angles will more or less break when this happens. Let’s hope this shift will happen swiftly and well coordinated.

Going unprefixed with border-radius?

Can you believe it’s more than 6 years ago that the WebKit team implemented border-radius? Looking at the support tables you can see that basically all browsers now support the border-radius property unprefixed. (Unfortunately Firefox 3.6 seems stuck with a long tail, but if you don’t care about that remaining 8% you can now safely dump those prefixes.)

Edit: There are still several dozens of mobile WebKit-based browsers, so you might want to hold on to those prefixes a little while longer. Also, Firefox 1.0 implemented -moz-border-radius back in 2004 already…

All of the layout and rendering issues with border-radius have been fixed in the meantime, allowing you for example to make a simple class for completely round corners when you don’t know the height of the element:

.radMax {
    border-radius: 999px; /* when it needs to be really round */