When I opened my inbox this morning, I nearly fell over. According to Daniel Glazman, co-chair of the CSS Working Group at the W3C, browser makers are considering supporting the WebKit vendor prefix (-webkit-*) because the web development community can’t be bothered to use the equivalent experimental properties for other browsers:
WebKit, the rendering engine at the heart of Safari and Chrome, living in iPhones, iPads and Android devices, is now the over-dominant browser on the mobile Web and technically, the mobile Web is full of works-only-in-WebKit web sites while other browsers and their users are crying. Many sites are sniffing the browser’s User-Agent string and filtering out non-WebKit browsers. As in the past with IE6, it’s not a question of innovation but a question of hardware market dominance and software bundled with hardware. But there is an aspect of the problem we did not have during the IE6 era: these web sites are also WebKit-specific because they use only “experimental” CSS properties prefixed with
-webkit-*and not their Mozilla, Microsoft or Opera counterparts. So even if the browser sniffing goes away, web sites will remain broken for non-WebKit browsers…In many if not most cases, the
-webkit-*properties WebKit-specific web sites are using do have-moz-*,-ms-*,-o-*equivalents. Gradients, Transforms, Transitions, Animations, border-radius, all interoperable enough to be browser-agnostic. Their web authors need only a few minutes to make the site compatible with Mozilla, Microsoft or Opera. But they never did it.Without your help, without a strong reaction, this can lead to one thing only and we’re dangerously not far from there: other browsers will start supporting/implementing themselves the
-webkit-*prefix, turning one single implementation into a new world-wide standard. It will turn a market share into a de facto standard, a single implementation into a world-wide monopoly. Again. It will kill our standardization process. That’s not a question of if, that’s a question of when.
This idea has been floated in conversations for a few years, but this portion of Dan’s post represents an official discussion at the CSS Working Group. An official discussion that Adobe, Apple, Disruptive Innovations, Google, HP, Microsoft, Mozilla, Opera and the W3C were all participating in.
While it is true that writing them all out is tedious, vendor-specific prefixes serve a very valuable purpose: they allow a browser manufacturer to experiment with a property before it becomes an official part of the spec. And during that experimental phase, the syntax can (and often does) change. If you use vendor-specific prefixes, you do so at your own risk. That’s not to say you shouldn’t use them, but it is to say that you should be careful about when and how you use them.
The value of vendor-specific prefixes is not really in question here though; they are not the problem. We are. We are apparently too lazy to implement CSS in a consistent cross-browser fashion. WTF?!
Please, I beg you: Take 10 minutes out of your day today and update every site you can to use the other vendor-specific prefixes (and non-prefixed) versions of each -webkit-* property you find, even if you’re not sure it exists yet. And if you need help, ask.
UPDATE: If you want to scan your server for files that might need adjustment, try this from the command line:
| find /var/www -type f -name "*.css" -exec grep -il "webkit" {} \; |
If you want to run it locally on a Mac, you should change the folder to ~/Sites.
UPDATE #2: I created a petition and a pledge:
- Tell Microsoft, Mozilla, and Opera not to implement the
-webkit-*vendor prefix, and - Pledge to update every site you can to use the other vendor-specific prefixed (and non-prefixed) versions of each
-webkit-*property you find, even if you’re not sure it exists yet
Sign the petition “Don’t make -webkit- prefixes a de facto standard” on Change.org.
Comments
We need a parser that searches for -webkit-* rules without corresponding -moz-* or -o-* or -ms-* or prefixless rules and adds them, a la an automated http://css3please.com/. Does anyone know if such a thing exists already?
Something along these lines?
http://leaverou.github.com/prefixfree/
Prefix Free is certainly one solution (I did something similar with eCSStender years ago). But if you want your properties to work without JavaScript as well, they will have to be hand-coded.
CSS pre-compilers like SASS and LESS offer an easy way to manage vendor prefixes as well by abstracting them out.
Of course Prefix Free and these pre-compilers don’t necessarily manage the nuance of support well. For example, in recent history Mozilla had a different single corner
border-radiussyntax and WebKit didn’t like spaces inside the parentheses of:nth-child()selectors. The extensions I wrote using eCSStender managed that nuance a little better without you having to know about it. It still required JavaScript, but could figure out what the browser needed to get based on testing for selector, property, and value support.Apparently Remy Sharp has a similar idea, and unlike me he’s smart enough to build it. ;)
http://remysharp.com/2012/02/09/vendor-prefixes-about-to-go-south/
it’s not hard to add the extra prefixes. It baffles me as to why this is a problem for so many. I mean, most of the time, all you gotta do is write the rule once, copy and paste it a few times and just swap out the prefix.
I’ve been using Nettuts’ super-helpful Prefixr:
http://prefixr.com/
The entire premise of “works-only-in-WebKit” is wrong for a billion reasons. Let’s start with “works.” Should any of these css3 properties actually break a page? Of course not. It’s a little extra flavor, rounded corners or transitions or what-have-you. The idea of progressive enhancement- or even if you’re into a top-down approach or something entirely different- says that there is no “breaking”, just “less like the perfect design.” Then the “only in WebKit.” Really? “only in IE6.” “only on Netscape Navigator.”
Hello, 2001. Please exit to the left. Thanks. Don’t come back.
Before I go much further, I’ll cede that I’m probably preaching to the choir here.
This decision is absolutely terrible. Thanks for the post. We should all do our part to stop this madness.
Maybe I’m talking rubbish, but the browsers could not make the interpretation of the properties without the use of prefixes?
Ex: If you used opacity, the mozilla know what to do, and you dont need to put a damm -moz-
I don’t get what the problem is, most professional sites are built with progressive enhancement in mind.
I.e. a site has a modal with a -webkit-box-shadow and maybe a bigger border on the side for browsers that don’t support box shadow.
Maybe in Firefox there is no shadow, or no border at all, but what gives? I would find it absurd for Mozilla to start accepting a -webkit- rule, confusing everyone.
There might be authors out there who write their CSS3 with incomplete prefix rules (e.g. I myself, in all these years I’ve never used an -o- rule.) I think in this case it’s up to Opera to support box-shadow as well as webkit so they don’t have to prefix.
“Their web authors need only a few minutes to make the site compatible with Mozilla, Microsoft or Opera. But they never did it.”
Well most likely because they won’t get paid by clients for this sort of fix, or it’s just a progressive enhancement anyway and other browsers might fall back to background-images instead of gradients for example.
Wolf, the vast majority of “mobile” sites, professional or not, are built with browser-sniffing all over and use prefixed things for way more than progressive enhancement. They are not built with progressive enhancement in mind at all.
This includes major sites operated by Google and other companies who are quite “professional” in terms of their web sites. As in live or die by them.
Best thing to do is for everyone to start removing browser extensions on their sites and use Modernizr to put those in dynamically. I belive Modernizr does this. I plan to update my CSS file soon.
There is so much crazy in this proposal. If all browsers start adopting -webkit, does that mean that Firefox, say, could introduce a new -webkit-property that webkit itself hadn’t introduced? The mind boggles. And what if, like in gradients, different browsers use different patterns. Do all browsers have to go with whoever got there first, just because they’re all using the same prefix?
I just can’t understand the thinking here.
pretty smart idea…
There is so much crazy in this proposal. If all browsers start adopting -webkit, does that mean that Firefox, say, could introduce a new -webkit-property that webkit itself hadn’t introduced? The mind boggles. And what if, like in gradients, different browsers use different patterns. Do all browsers have to go with whoever got there first, just because they’re all using the same prefix?
Apostas,
The thinking, I feel, is revealed by the sort of comment made in the minutes of the meeting:
Florian: We are currently losing market share because of not implementing webkit properties.
“Market Share”.
It’s almost like listening to some corporate big wig talking about profits or revenue.