The Vendor Prefix Debate

| 0 comments

There has been a lot of discussion lately on blogs and Twitter about the use of vendor prefixes, and I’d like to add in my two-cents.

I initially came across the whole thing from Chris Coyier at Css-Tricks.com, followed by tweets from various web professionals on Twitter. Essentially, Mozilla (those behind the Firefox browser) wants to provide support for Webkit’s -webkit- prefix (that is used by browsers like Safari and Chrome that use the Webkit engine). A lot of people are saying this is a bad idea. Others are also saying we (the designers/devs) have gotten ourselves into this mess. I think it really comes down to all of us – the browser vendors, the W3C, and the web designers/devs.

The browser vendors have their own set of prefixes that they use for experimental purposes – it is pre-standardized code, and prefixes are not spec. Firefox uses -moz-, Safari and Chrome use -webkit-, Opera uses -o-, and Internet Explorer uses -ms-. Apparently, web designers/devs are using the -webkit- prefixes only, to use properties we call “CSS3”, because they either don’t know about the equivalent prefixes for other browsers, or don’t bother (sometimes, though, they don’t exist). Technically, some of these fancy schmancy techniques we use with prefixes aren’t really CSS3 – yet, anyways depending on how far along they are towards W3C recommendation. Many of these techniques are kind of like previews, and allows the browser vendors to test stuff out (as well as designers/devs too, who can provide feedback). Some browser vendors are already supporting standardized CSS3 properties. But the support varies with each browser vendor, and some browser vendors are using their prefixes to test things, and not all are testing the same things.

Part of the problem, that other people have brought up, is the browser vendors should use these prefixes only in non-production releases. I agree that really, really, experimental properties shouldn’t be in production releases, because I think that’s where issues arise if they are used for production websites. But I think those prefixed properties that work great (no bugs, etc.) should be available so that designers/devs can play with them now, even in production websites. And, the browser vendors should submit implementation reports so that the way they are implemented could potentially be the standard in the W3C specification.

So because we can, designers/devs are using these prefixes to enjoy using these fun CSS3 properties now. What Mozilla has a problem with, is designers/devs are using only the -webkit- prefix, and nothing else. That means any fancy tricks that are showing up in browsers that support the -webkit- prefix will show up… but not for the other browsers, such as Firefox. So they want to support the -webkit- prefix (which other browser vendors like Opera and Microsoft might be eyeing at now) so that websites viewed in their browser looks just as good.

I think that’s where a BIG part of the problem really lies. It’s with the designers/devs. Personally, if I am going to use some sort of CSS3 technique, I use all the available vendor prefixes, and put the W3C spec version at the bottom of the stack as a fall back in hopes that all browsers will support the spec version one day (though it will probably be awhile before we can not use any vendor prefixes at all, as older browser versions will still need the prefixes).

Why are designers/devs not using stacks for CSS3 properties? We use font stacks. Why is this different?

It could be lack of time to test in other browsers for projects that are on a tight deadline. It could be laziness. Whatever the reason, it needs to stop.

I use stacks for CSS3 properties so that they work in as many browsers as possible, but also in the hopes that eventually we will be able to just use the spec version one day – future-proofing! And it only takes an extra minute, if that, to support the other browsers. I also don’t use extremely experimental properties, or ones that only work in some browsers (unless it degrades nicely… I don’t want weird stuff going on).

Then, that is where we have to look to the W3C. Css3 has been split into different modules (you can see how far along each module is at Css3.info). Many are still in Working Draft, and the process can be slow. It is great that the modules are split however, so that they can all progress at different rates, but it is still a very slow process, especially since CSS 2.1 isn’t even at full Recommendation yet.

So I think in the end, it comes down to all of us working together. The W3C needs to work at moving things along a little faster if they can, because we’re all itching to use these new CSS properties. Browser vendors should stick to their own prefixes, work at making them better so we’ll want to support them, and start to support more new CSS properties as they become spec. And most importantly, as professionals, web designers and developers need to support ALL browsers as best as possible, and use the spec version at the bottom of the stack. We need to provide a fall back for older browser versions, and future-proof our work too.

As Kevin O’Leary would say… stop the madness!