Big question: are vendor prefixes hurting the web?

Henri Sivonen wrote a post entitled Vendor Prefixes Are Hurting the Web and Daniel Glazman wrote a response, which sparked quite a debate. So what do our experts think?

Chris Coyier
chriscoyier.net

Would we be better off now if browsers never used vendor prefixes? No. There would be less innovation, more bugs, and inconsistent implementations of features.

Would we be better off in the future if browsers stopped using vendor prefixes right now? No. Same issues as above, but also there are too many authors using them and too many released browsers that support them to go cold turkey and see any benefit.

To make things better, the answer is to keep raising awareness as to their proper use and encourage authors to keep their work up to date.

Chris is a web designer working at Wufoo

Jonathan Smiley
zurb.com

I agree that writing out the vendor-prefixed properties is annoying, but what’s the alternative? If we have to wait for browser makers to agree it will take forever, and if they were to implement competing implementations before a final spec we simply wouldn’t be able to use them. Vendor prefixes let browser makers nudge the standards groups into finalising things, and we get to play with them in the meantime. I’ll use what I can get my hands on, and I’d rather have something somewhat annoying than nothing at all.

Jonathan is a design lead at Zurb

Margaret Manning
www.readingroom.com

I disagree with most if not all of Henri Sivonen’s post. “Vendor prefixes are hell for web authors and authoring tool vendors”. Speaking as a web author I think this is nonsense. I choose to use CSS prefixes when I think they are beneficial to a project, they are not forced upon me by browser vendors.

“Vendor Prefixes are Hurting Browser Users and Competition”. Again I disagree, if anything I think prefixes help browser competition and push uptake of new standards across browsers. I think one major browser implementing a host of new features (even if experimental) drives other major browser vendors to up their game and start supporting cutting edge features too.

As for browser vendor demos, obviously Safari’s demos use only webkit prefixes – they are trying to get people to use Safari! The thing is, for most people, using another browser than the one that they are currently using doesn’t even enter their thoughts, I know countless people who don’t even bother updating the browser they have, let alone changing to the latest and greatest release of the moment. People who are more technically minded or in the web industry will immediately query why the Safari demos don’t work in other browsers, I myself view the source and inspect the CSS of almost every site I visit (but that just could be a unhealthy habit of mine!).

“I think when browser vendors implement a feature experimentally, the feature should stay in experimental builds (nightly builds, ‘labs’ builds or similar) until it is close enough to a final design that it can be taken as a constraint for future changes to the feature.”

This is one of the only points that Daniel Glazman agrees with, again I disagree with this idea. I think CSS vendor prefixes should be kept in stable releases of browsers as opposed to experimental builds, I feel this would mean that they would actually be used in the wild, this lets web authors get used to any differences that may exist between rendering engines for specific features and means there will be more people to complain about any inconsistencies and give feedback to browser vendors.

It’s also worth remembering that once a browser implements a non-prefixed feature that was prefixed in an earlier version, it will apply the a non-prefixed style if it appears after the a prefixed version. So if for example browser X v.4 did funky things with X-border-radius, v.5 could have the correct implementation and dropped the prefix, so both V.4 and V.5 can enjoy nice round corners.

Who needs to act? Some major browser vendors need to shorten their release cycles, I’m looking at you Internet Explorer!

Margaret Manning is CEO of web design and digital marketing agency Reading Room

Simon Holywell
www.simonholywell.com

Vendor specific prefixes are a great way to expose experimental features to developers and end users without infringing upon the CSS namespace set out in the specifications. They allow us to try out new features and gather vital feedback for browser vendors from us and our users, which may help to improve the final specification for a given property.

Equally, however, it’s painful to have to update a number of different vendor prefixed properties that affect the same aspect. Another potential problem is that once formalised in the specification should the vendor specific prefix support for that property be dropped or maintained to preserve backwards compatibility?

There is no silver bullet, but I think that the vendor specific prefixes solve the issue we are facing right now. Sure there are problems, but I am yet to see a better approach in practice. If you do not like them then avoid implementing experimental CSS properties that have yet to reach candidate recommendation status with the W3C.

Simon is lead developer at Brighton agency Mosaic

Daniel Bramhall
bramhall.me

I believe that vendor prefixes are actively harming web standards and make developing for the web unnecessarily voluble.

How can one develop for the web efficiently when to declare a simple border radius, three different declarations are needed (and that’s just to support three out of the dozens of widely used, popular browsers)?

Daniel is a Mac OS X and iOS interface and application developer

Elliott Fienberg
auditory.ca

Browser prefixes sure are a pain to work with, but if it means that we’re able to use new features as they’re developed, I don’t have a huge beef. Of course this kind of apathy isn’t helping the situation, but there doesn’t seem to be a clear cut solution that we can all get behind anyways.

Elliott is fighting the war on bad music with his cold, dead hands

David White
www.spry-soft.com

No, CSS prefixes aren’t hurting the web but allow us to use new CSS features before a browser has fully implemented them. I treat vendor prefixes as CSS features still in beta, prefixes such as -webkit or -moz allow browsers to provide experimental features without adding them directly to the global namespace. This allows developers to use these features to target specific browsers where the same feature in a different browser may cause an undesirable effect.

David White is a website designer and developer currently working at the BBC

Paul Rhodes
www.22blue.co.uk

They’re both good and bad and will continue to divide opinion depending upon who you are. Web developers have come to accept (in part) the CSS prefixes of webkit, mozilla and so on. So thumbs down for convention and ease of use. But they are essential to vendors to drive innovation and experimental features. The dogma surrounding web standards stifles innovation. Thanks to the vendors for making use of these prefixes otherwise we’d still be creating rounded boxes as graphics while page one of the standards is written (in draft of course). However, it’s a short-term solution and there is a limit, we don’t want too many vendor prefixes to remember and code. I guess the bottom line is for standards to reign supreme they must be quicker to the party.

Paul is founder of 22 Blue (22blue.co.uk)

Rob Hampson
robhampson.co.uk

Like Ewoks, vendor prefixes are plentiful and mildly annoying. I wouldn’t say they were massively hurtful. For example, using multiple prefixed syntaxes just to implement a border radius is a pain, but is it harmful? More often than not prefixed syntaxes are experimental features that haven’t made the grade yet. I say keep them in controlled dev/beta versions. When a universal syntax is justified and included, ship in a stable public release.

Rob Hampson designs for web and print and also creates illustrations

Robert Pataki
heartcode.robertpataki.com

Personally I don’t think they’re hurting much. They are experimental features that should be handled with care. If you are about to deliver web content you can always decide if you go for richer experimental stuff that isn’t widely supported or use old methods to make sure everyone gets the same old thing.

If the lack of the implementation doesn’t affect the presented information I believe it’s fine. It’s all about decisions we have to make anyway as we still have to support old browsers in other ways.

To me prefixes mean enhancement, experiment and progress. We already see how they affected browser vendors to speed up their release cycles and force each other (and the users) to keep up with the latest technologies. I also believe that prefixes help W3C and browser vendors to reach the standardisation milestones faster and highlight important issues much easier.

Robert is a developer at Waste Creative

Andy Pike
1minus1.com

Vendor prefixes are seen by some as a messy, non-standard solution that hurts the web. I disagree. In fact, I believe they have helped move the web forward. Take the CSS3 standard border-radius declaration. This has been available since FireFox 1 as -moz-border-radius. Developers haven’t had to wait for the official standard to be released to use it. The border-radius declaration only arrived in IE9 in 2011, should we have waited 6 years? This is where progressive enhancement improves UI, which in turn drives standards.

Andy is technical director of 1minus1 Limited

Joe Lambert
joelambert.co.uk

No, vendor prefixes give developers a way to test drive experimental features in real world scenarios before they are standardised. Without prefixes we wouldn’t be able to create the kind of compelling mobile web apps that are possible today. Also, with tools such as Compass and SASS the argument of having to “say the same thing in a different way to each browser” in practical terms is a non issue.

Joe is the creator of Flux Slider

Steve Cross
theartfulbadger.co.uk

We’ve been beating the ‘progressive enhancement’ drum for a long time now, I’m surprised that we’re not celebrating vendor prefixes as a way of providing cutting edge functionality while also allowing old or ‘late to the party’ browsers to tag along too.

Clearly, the code isn’t as tidy and I’m always thrilled when I know that another browser is accepting non-prefixed styling but there are a number of tools that help mediate the code bulk and the opportunity cost is one of innovation.

I suppose, if you want me to stop using vendor prefixes, I should also stop using pseudo elements given their patchy support in IE7? IE7’s still got a user-base I should cater for, right? Hell, why not build with tables – at least I know it renders in 6.

Building for the lowest common denominator stalls innovation and that harms us all. In a world without vendor prefixes, we’ve ground to a halt.

Steve is a frontend developer and co-founder of Rareloop