Over the last week I’ve been following a few peoples views (PPK, Remy Sharp and Stef. Sullivan Rewis mainly) on Microsoft, Mozilla and Opera supporting -webkit- prefixes in their browers, here, here and here. Oh and on Twitter too. (This post is a little delayed due to the fact I’ve been doing some testing in CSS before writing this.)
Microsoft, Mozilla, and Opera are now going to support the -webkit- prefix, all because the development of mobile websites focuses on Webkit based Browsers( iOS basically ). The reason this is happening is because Web Developers are lazy. Instead of supporting browsers properly, they are only supporting Webkit based browsers. There are some CSS3 features that are supported by all browsers, like Gradients, Animation, Transitions, border radius for example, so it’s not like you can’t support these.
I admit this is a lot harder than for desktop browsers. Its easy to install a desktop browser than it is to get different Mobile phones with different browsers. I’ve found though, that even if you can’t get the phone, there are Mobile browser simulators for Opera, Fennec (Firefox), an Android emulator and you can also get an iPhone emulator for Mac with XCode. I know this is not the same as testing on the real thing, but its better than nothing.
Now the main concern surrounding the -webkit- prefix is that people think Webkit is becoming dominant over the web (much like IE6 back in the day) and that its “turning one experimental implementation into a standard.” There is also a concern that it will break websites, say if Firefox does a feature one way and Safari does it another. The reason Webkit is becoming more dominant is because we are letting it, but not everyone has a iPhone/iPad, plenty of people use Android ( like me, although I do want an iPhone ) so the war is not lost. On my phone I have the Native browser (some Webkit based one), Firefox and Opera Mobile to test on. I can also test on my iPod touch which has iOS 5 on it.
The Current Prefix System
The current system is flawed, I’m probably not the only one to think so. No one wants to have to type a lot of browser specific prefixes for some CSS:
-moz-border-radius: 8px; -webkit-border-radius: 8px; -o-border-radius: 8px; border-radius: 8px
but we do because we have to if we want to use those features in all browers. Its not too bad for CSS manipulation in say, jQuery, as some cssHooks exist to normalise this for you.
The Current Work Around
I don’t think it will break the web, we have got over different implementations in the past. If you think about what you had to do in the first place, taking CSS3 gradients as an example, you would do:
background-image: linear-gradient(red,blue); background-image: -moz-linear-gradient(red,blue); background-image: -webkit-linear-gradient(red,blue); background-image: -webkit-gradient(linear, red, blue)
So the browser would choose which one to use. This is the same for background-color when rgb(a) and hsl(a) were added:
background-color: #000000; background-color: rgba(20,20,20,0.6);
Putting them in this specific order (stating the obvious I know) means that the background colour will start off being #000000, but will change to rgba(…) if that browser supports it. If we now think about how it will work when browsers change to all using the -webkit- prefix, its not that bad.
If a new property was added called “awesomebox”, and Firefox supported it will percentages, Chrome with decimal etc, it would work, you would just have to list each incarnation, much like with the background-color example above:
-webkit-awesomebox: 90%; -webkit-awesomebox: 1.0;
You would only run into problems if Firefox supported (hypothetically) a set of strings or percentage, and Chrome supported a different set of strings or decimal. If you were to both use strings then I think none of the styles would be taken into account.
I think some people forget that these properties are still in development and are experimental, so they will have bugs and are likely to change. Remember what happened with the Gradient Spec and Webkit. They did it one way, Firefox did it like the W3C specification, then Webkit changed to the W3C specification way.
I do admit it doesn’t make sense to put -webkit- into the spec, mainly because you wouldn’t associate the -webkit- prefix with Firefox, IE and Opera for obvious reasons. That was the point in their own prefixes, as they supported some features differently. What does make more sense is to have -beta- instead and avoid this kind of confusion. I like PPK’s idea of -beta- and-alpha- prefixes, as the prefix can change when the implementation changes. Remy sharp suggests that experimental CSS properties should be production ready browsers only. This is an interesting thought 50/50 on it really as I can see the benefits for and against it.
What does worry me if it starts with browsers changing to the -webkit- prefix, will browser vendors then only support Webkits implementations instead. Only time will tell.
A Permanent Fix
The only way to stop this happening would be to get rid of the old prefix system, and add a -beta- prefix to be made a standard. This means for browsers that do support CSS implentations in the same way, less CSS is needed. If we take the border radius example and apply the “new” system to it:
-beta-border-radius: 8px; border-radius: 8px
we would only have to use 2, which is easier to implement if you were doing more that one feature.
I don’t think Webkit will become more dominant as long as, we, the developers, don’t let them. This is not IE6 all over again!
I’m all for change but I don’t agree with browsers all using the -webkit- prefix. I would rather it be a -beta- prefix instead and the current system be removed.