Perplexing Prefixes

Mostly I wanted a title with a little alliteration (like that sentence). What I am talking about in the title are vendor prefixes for CSS, those little bits of words and dashes that appear in front of what would otherwise be a W3C CSS declaration, but denotes that this one is actually an experimental or beta implementation of the specification by that particular browser.

Continuing with the recent trend of smart people in the know openly and publicly debating issues that do and will continue to affect web developers, Henri Sivonen wrote an article earlier this week with his main point right in the title: Vendor Prefixes Are Hurting the Web. For those of you who are curious but don't want to wade through his entire post, he has a tl;dr version:

I think vendor prefixes are hurting the Web. They are hurting Web authors. They are hurting users of browsers. They are hurting competition in the Web browser space. I think we (people developing browsers and Web standards) should stop hurting the Web. It would also make sense for browsers to implement other browsers' prefixed features to the extent existing content uses prefixed features.

He is kind enough in his post to include some counter arguments and preemptively respond to them, including linking to other counter arguments that are direct responses to him. Alex Russell provides his own tl;dr version in his response, Vendor Prefixes Are A Rousing Success:

Henri Sivonen's arguments against vendor prefixing for CSS properties focus on harm without considering value, which in turn has caused him to come to a non-sensical set of conclusions and recommendations. Progress is a process, and vendor prefixes have been critical in accelerating that process for CSS.

Daniel Glazman provides a point-by-point counter argument in his post CSS vendor prefixes, an answer to Henri Sivonen. He doesn't provide a tl;dr version, so I am using this quote in place of one:

The ineffable Henri Sivonen has contributed a long, a very long, a probably too long post about CSS Vendor Prefixes. In short, he thinks they are harmful and should be dropped. I tend to totally disagree and will explain why below.

My opinion

Nobody has asked for it, but you did choose to come here and read this far, so I guess you deserve it.

I think that prefixes have their place, and codifying their non-standard behavior (as in, there is no standard in place to describe how the feature should work) with a prefix makes for a very readable, consistent method to identify this non-standard chunk of code along with what rendering engine relies on it. Ideally it also makes for a consistent way to run a regex or search and replace to adjust or clear them in the future.

Web developers who implement these pre-standard features run the risk of creating a hassle for future maintenance and need to consider if they are just being bleeding edge or solving a real need. When working with clients or on projects where once it launches it is unlikely to see regular updates, it's unlikely that someone will come through and clean these up until there is an overhaul. When you see these all over a site, it's not the vendor prefix hurting the web, it's the sloppy or short-sighted developer who is relying too much on them and not building a process to excise them down the road when the time is right.

Companies who build vendor prefixes into their CSS/DOM editing tools are doing a disservice to developers. Promoting support for every browser while offering the most cutting edge features ends up putting developers who rely in these editors in a tough situation. Without exposing them to the code or providing an easy way to manage these non-standard features, more of this bloat makes it into the page. The proliferation of abstraction layers compounds the chaos. Removing the developer from the code and failure to educate the developer on the implications of his or her choices is the issue in this case, not the vendor prefixes.

I do agree with the assertion that sample and demo code across the web (such as tutorials) that shows off new CSS features does not get updated, so developers may use it in all its vendor-prefix glory well after a feature has been standardized. These samples need to do a better job of managing the reader's expectation that the standards may have changed and the code may be out of date. It's still up to the developer, however, to choose good and recent examples that are appropriate to the need. Not understanding the code being copied is not an excuse, it should be a clue that the developer needs to spend a few minutes reading.

Removing vendor prefixes can stymie the real-world use case testing of feature implementation that is hard to come by when looked at from a purely academic view. Suggesting browsers support one another's prefixes means if one vendor changes the feature, all the others would have to follow suit, regardless of the existing (or lack of) specification.

I do like the idea of vendor prefixes only in the experimental builds of browsers, but then developers may be disappointed that their favorite new bleeding edge feature won't work for regular Joe users.

This isn't a simple issue, but getting developers to be more responsible and judicious in their use of these new properties would certainly help.

Related

Peter-Paul Koch broached this very topic way back in March 2010 with the post CSS vendor prefixes considered harmful and his follow-up (based on reader reaction) CSS vendor prefixes redux.

While I instruct my team to avoid vendor prefixes, I have warmed to them for experimental projects or sites with a greater likelihood of ongoing updates (where the client expectation has been managed). In my post The evolt.org Logo Using Only CSS2 and CSS3 I make extensive use of vendor prefixes, just to show it's possible. The opening image of this post is pulled from a JSFiddle I made of a CSS3 cube to submit to Chris Coyier's CSS shapes article (although it isn't in there — yet).