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.
If you’ve ever tried to get precise em-based values of
letter-spacing to work in a WebKit browser, you’ve probably wondered why that isn’t really possible, while Firefox or Internet Explorer 10 for example do allow fine-grained control. Play around with this demo in various browsers and you’ll see what I mean.
The underlying reason is that WebKit currently uses integers to calculate pixel positions, while Firefox allows subpixel units to represent locations and sizes. This affects not only letter-spacing of course, but also things like rounding errors while zooming or applying transforms. There has been an ongoing effort to switch WebKit to use subpixel layout, and a few days ago Levi Weintraub and Emil A Eklund landed a patch that should put subpixel layout on the fast track. Look forward to more precision coming soon to WebKit-based browsers.
Here’s some technical background on this matter, and an article on subpixel rendering and the CSS Object Model from the IE team.
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.
Sometimes it may look arbitrary if a browser maker decides to use a vendor prefix or not when implementing new features. But it’s not some haphazard affair – there are pretty elaborate rules for this.
By the way, the easiest way to check if you should use vendor prefixes or not is still caniuse.com!