Vendor prefixes are not developer-friendly
or…
The premise of prefixes makes unrealistic demands on how developers maintain sites
There's a lot of conversation about making prefixes work (by changing policy), but I believe they already are at odds with the developer workflow. In this proposal I hope to show that:
- prefixes are not developer-friendly
- recent features would have been in a much better state without prefixes
- implementor maneuverability is not hampered without prefixes
The developer experience
If I'm using a feature that's prefixed, I have a choice of using a tool to help me manage outputting the various prefixes I need or I'll do it myself. Based on my informal poll last week it looks like 40% of developers are not using tools. Without tool usage, authors are not including -ms-, -o- or the unprefixed variants. Page 4 of Mozilla's prefix report verifies this; developers don't write necessary prefixed properties about half the time (e.g. -o-transform) and in fact, they already write out the unprefixed variant well before the spec goes to CR (and do this well before adding in -ms- or -o- compatibility).
This matches my experience as well. I don't want to return to this code to maintain it, so I'm going to add the unprefixed version. There is less of a cost to me leaving the unprefixed version and assuming I won't need to change it vs. returning to my CSS of shipped-to-production work to add unprefixed variants each time a feature hits CR.
Any successful evangelization plan for prefixes relies on tools, but all tools prioritize the unprefixed state. prefix-free, compass, and css3 please (I'm a tool vendor, too) all heavily suggest starting with the unprefixed state. So any successful evangelization push will just result in the unprefixed version being 100% deployed from the get-go, which ties implementors hands anyway and defeats the purpose of the prefix. I don't have data to show that developers are not returning to their deployed, production code to update prefixes, but anecdotal evidence suggest so. Opera’s Web Opener team, for example, reports a <10% success rate when directly contacting sites to request updates to their prefixes.
PPK wrote “If standards make web developers’ lives much harder, web developers ignore standards. This was true back in 1998, it’s still true today.” Without prefixes, implementors have an opportunity to empower developers to do the right thing while still allowing room for innovation.
Existing W3C prefix policy provides false expectations
PPK covered this ground well last week, but in short the policy of binding prefix-drop to CR has failed plenty. Developers have no expectation of when this will happen, nor should they. Mozilla’s roc has confirmed developers are using prefixes and they won't stop regardless of their supposed "experimental" status.
Let’s imagine there were no prefixes
So without prefixes, vendors hands would be tied and the first implementation to ship would be the one to stick, right? Nah. I think we can walk through a few examples from recent history too see what it would have been like if there had been no vendor prefixes in play.
transitions, transforms, animations
While plenty of implementation bugs were fixed, the developer would never have updated their syntax and would have complete browser support.
box-sizing
No problems. No changes.
css-gradients
Gradients has been the most tumultuous css spec, but if they had been implemented without prefixes, the feature would be in a better situation today.
Browsers discard properties and values they don’t parse successfully, so developers would have just included a cascade of the iterations of the spec. This would have successfully targeted all shipped versions of gradients:
.blacktowhite { background-image: gradient(linear, left top, left bottom, from(black), to(white)); /* initial webkit proposal */ background-image: linear-gradient(top, black, white); /* mozilla proposal */ background-image: linear-gradient(to bottom, black, white); /* likely the CR */ }
flexbox
Mozilla started Flexbox v1, WebKit followed with a slightly stronger implementation. Both Alex Russell (post) and I (article) recommended boilerplate code that assumed no change for unprefixed state and blocked out IE10’s upcoming implementation.
Flexbox v2 debuted and has an implementation in Chrome. Syntax is already different enough that the fallback story is happy. Without prefixing, the resulting browser support of shipped author code would be better. Again, I see no drawbacks in this example had these properties not been prefixed.
requestAnimationFrame
Soon after this feature debuted, shims were written to manage all prefixed implementations including the unprefixed state. (Sorry). Combined with quick adoption, browser have as much ability to change the feature as they would if it were unprefixed to start (that is, not much ability).
Risks and Resolutions
In CSS, new breaking changes have to introduce syntax changes that would break previous parsing attempts, as seen in the gradients example. However, if the semantics of a feature changed without syntax changes, we’d have a situation where developers are forced to detect each behavior and write compatibility code.
border-image introduced a similar situation recently: WebKit changed its semantics and required a `fill` keyword to match previous behavior. Sounds like trouble, but this change happened when the unprefixed variant was exposed, matching implementor best practices of changing a feature. The result: Greg Rewis of Adobe blogging that Chrome broke his site.
This is truly how it is supposed to work, but still expectations are broken. Developers have plenty of motivation to leave in the unprefixed state at the beginning, but this means that any change will always break them. With prefixes or without prefixes, we would have gotten the same resolution here.
In JavaScript/DOM we have a more secure safety net, as behavior can be detected. Take for example querySelectorAll(); it was shipped without prefix and while implementation differences exist, JavaScript libraries detect and route around them. Of course, semantics can change and the prefix → unprefix move provides an opportunity, but in my experience it’s more common to see these changes happen early on (like blob.slice()’s change).
Without prefixes there will be no mechanism to notify developers “beware, thar be dragons!”. Prefixes don’t do this now, as their removal isn’t prioritized so developers accept them as a fact of life rather than an indication of instability. The solution: getting accurate metrics of feature usage and adoption can inform implementors of if it’s too late to change a feature or still early enough to modify.
Yes, but…
As vendor prefixing is a well-worn debate, allows me to deflect common challenges to this proposal to:
- Vendor Prefixes Are Hurting the Web by Henri Sivonen (see “Pre-Emptive Rebuttal to the Most Common Counter-Arguments” and on)
- Alternatives To Supporting -webkit Prefixes In Other Engines by Robert O’Callahan
- CSS vendor prefixes considered harmful by PPK (from 2010)
Logical Actions
- The community to evangelize use of tools like Compass that protect authors from bad authoring practices and so folks who publish tutorials don't solely define their
-webkit-styles. - Browsers to track feature adoption to inform better decision-making around changes. (Answering the question: Are we stuck?)
- This data should be public and update regularly.
- Should be based on pageviews, to accurately weigh when a CNN.com implements something
- Other browsers to implement a defined set of
-webkit-prefixes on their mobile browsers. I don’t see a way around this nor do I think it’s bad. - Drop the notion that evangelism gets us out of this mess. I've been doing this evangelism myself for the past 3 years, but I'm also a realist. This situation needs new policy and (clearly) needs speed out of the CSS WG.
- Browsers to clarify a feature detection strategy that it supports. For example, developers have no reliable way of detecting Chrome’s 3D transforms support [1, 2] or discounting Chrome’s -webkit-hyphens false positive[3]. All proposals for handling experimental properties need accurate feature detection techniques to be effective.
In summary, the ideal developer experience is 1) using tools to manage prefixes and 2) always using the unprefixed state to reduce maintenance cost. These two facts eviscerate the benefits that prefixes were introduced for, leaving only the drawbacks.
Compass is fantastic, but it's a simple truth that there is a percentage of folks who will never use it. For whatever reason, they find it intimidating…or think it's exclusively for Ruby devs…or think it's overkill for writing CSS. A shame…but true; I see it all the time.
What I've also seen is a preemptive use of prefixed properties, even where not needed or appropriate; like border-radius.
Another problem is that people are creatures of habit. It is very hard to change their ways so that they include -o- or -ms-
As you (and I, but nobody knows) have said, it's probably going to come down to unprefixed PLUS all-round support for some -webkit- properties.
I wonder how much this whole -prefix-gate has ended up costing everybody. If nothing else, then on a bandwith scale.
The "creatures of habit" comment is specifically why tools are the answer, in my opinion. Let people code as much as possible using the official syntax, and then the tool handles the prefix aspect behind the scenes. I'm a huge Sass fan, but the reason why I've never fully invested in Compass is because there's a certain amount of memorization required. I can't always remember what these mixin names are called. We need to make this task as simple as humanly possible for people…or they, by and large, ignore these tools.
Jeffrey,
You've made a valid point. However, the reason why some probably don't use it is because it's not as streamlined in the workflow. Not sure if I'm missing anything, but from what I've researched, there are extra step(s) involved to get your newly saved Compass/SASS CSS uploaded.
How about this.
Website developers just use unprefixed code for their websites.
Browser developers just use unprefixed code for their stable, long term browser releases… that normal people use.
By all means use prefixes in edge versions etc for testing and to get feedback from devs.
By all means set up a "Browser Fight Club" to determine whose spec rules. (he he ;p)
Essentially though it's not up to web devs to worry about this, it's been happening for far to long and its about time the big boys shook hands, grew up and gave us little guys a break!
:)
@Michael – Uploaded? You mean to a server? Not really.
It used be an issue of working in the command line (scares some folks), but, now, tools like CodeKit, LiveReload, and SimpLess handle that part for you.
@Jeffrey Way
Jeffrey, I'll have to look into those. I'm hoping Coda 2 will implement something like this. Thanks for recommendations though.
@Jeffrey Way
Yup. I agree. I've been talking with Chris Eppstein about the compass mixins and he's working on a strawman sugar syntax:
I think syntactic sugar like this would help drive adoption of a common set of mixins, which would net out as being hugely helpful.
As a developer, I don't like the idea of using a third-party tool to solve the problem with vendor prefixes. The browser vendors need to re-think on how to approach this issue. I'm cross posting from my comment on Google+:
How about this? No browser vendor ships stable release with prefixes! In other words, any property that has a prefix should stay at nightly or beta.
There was a time when we needed prefixes. It was when W3C didn't tell vendors "how" to do something. Now, the spec actually entails how to go about implementing a functionality. This means if a vendor implements a feature (e.g. linear-gradient) and it behaves exactly as the spec, then that vendor should ship linear-gradient in the stable release without any prefix. If the feature is unfinished or incomplete, it stays at nighly or beta with the prefix.
This might sound insane but that is exactly what prefixes were meant to do years ago; allow vendors to develop without having to worry about things breaking or working half way through.
This is one reason why I'm a fan of Stylus. You can hijack these CSS3 properties, and extend them to use the necessary prefixes.
https://skitch.com/jeff_way/88cpt/stylus
So, if the community maintained a CSS3 Stylus file, designers can code with the official syntax, and never have to worry about what's going on behind the scenes.
Your assessment is way more succinct than mine. We are all feeling the pain of prefixes, while the theoretical advantages have long since gone away.
Unfortunately my SASS doesn't include all the prefixes, and I will probably never go back to fix it. I'm not paid to maintain the site as browsers change, but to work on new stuff.
I totally agree with @Adeel Ejaz
As long as prefixed properties are included in stable releases people will use them.
People, and specially developers just l-o-v-e their new shiny bling blings, and as long as one can show how bleeding edge his code and sites are (even if it's only on a week old version of chrome), no matter what the 'rules' will be he will use prefixed code.
I think that the browser vendors went into a race they lost control of.
There is no good reason to release a new major version every other week when almost all the difference between the versions is prefixed (==beta) code. The place for fixes is minor version and the place for new stable functionality is major releases.
The place to show work in progress should remain in the Canary/Aurora/Alpha/Beta channels.
(btw – As for MS and Opera, I think it's totally stupid they get to release browsers with prefixed properties with their long release cycles, either shape up and feature freeze what you can't complete or adept to the new reality)
Now that the Web has become the major business playground it MUST become a more stable place.
I place all the weight of this responsibility is on the shoulders of the browser vendors that must wake up and realize that what used to be their sandbox is now the world's number one playground.
I have a quick thought; I'm sure it may have already been discussed.
Has there been any discussion over having a "dibs"-based version prefix? (ex: -v1-gradient, -v2-linear-gradient, -v3-linear-gradient) Allowing all browsers to claim an attempt (or multiple) to get the syntax "correct", but giving all browsers the ability to back-fill popular prefix adoption (likely would be more *acceptable* despite really being the same as -webkit- adoption). There could be a simple wiki (or github repo) where a browser claims the next version number and drops in a quick footprint and which browser is claiming support (and maybe link to their docs). Obviously these numbers could grow to be large, but history shows typically only a handful of iterations.
It won't prevent devs from including an inappropriate guess as to the final syntax, but if we can expect reasonably long support (and potential back-fill) for out-dated versions, we can start to *teach* devs not to use final syntax until spec is final.
Not trying to argue or resist dropping prefixes… just curious.
So we have a community-based spec, enhanced by fragmented vendor prefixes, patched by community-generated, fragmented compilers. One might equate it to a zebra pulling a mule pulling a dead horse. To be clear, the state of the latter is not meant to reflect on the W3C's relevance and usefulness, but perhaps rather the thoroughness of its review process. The answer then is not to strip the mule of its name (again here, the choice of animal not intended as commentary on our charming browser vendors, but indeed selected for its physical characteristics, namely its literal capacity to drag a deceased horse), for the mule will still need to be reigned in, whether by browser- or feature-detection. Rather the ideal solution is to revive and reinvigorate our beloved, expired stallion such that it once again is leading the way.
the problem i see about prefixes is it's uncertainty of when it will be unprefixed, as it's "somewhere in the future" we take it as "will never be unprefixed" so all this mess happens, as you pointed out browsers should have a cycle for prefixes some time to test usage and implementation and some time after to drop it, I don't know how much time it will take, the people at de working group and browser makers should know better than us developers.
the mozilla/opera step through implementing -webkit- prefixes for me is a mistake, developers should stop being lazy and use some tool or write the prefixed versions down along with the unprefixed versions.
as mobile isn't much the market for Mozilla and opera they are just ignored by developers, it's sad to say.
@Paul Irish
+1 on making Sass/LESS/Compass syntax (almost) perfectly match real the real css it's abstracting. It's not a good idea to teach someone to use 'single-transition' or 'drop-shadow' when they will eventually be using the real css rule by a different name.
One example of where the use of non-prefixed properties would be harmful:
background-image: linear-gradient(45deg,#F00,#00F);
The angle argument has changed bearing in the spec, so if no prefixes were used you'd find one day that all of your gradients were going in the wrong direction.
I'm not saying prefixed properties is a perfect system, but its there for a reason and it does its job in most cases.
I also think this issue is somewhat in danger of being overblown. AFAICS only one element has been definitely identified as being prejudicial so far, and that's text-size-adjust – and even that's only used on 4% of sites: https://bugzilla.mozilla.org/show_bug.cgi?id=708406
Potentially bigger problems are relying on transition/animation events in JS, which could break key functionality, and people using -webkit- properties in browser sniffing, which is just downright hostile.
Erratum: "… even that's only being used on 4% of sites TESTED:"
If Mozilla and others implement -webkit- prefixes, the standardization process would be hurt, because features from Apple/Google browsers start to be de facto standard(not really, W3C has full control over unprefixed features). If not, Mozilla will be hurt and webkit based browsers on mobile will continue to have dominant marketshare.
Clearly, I would take Mozilla over some petty W3C every time. And isn't it partly their fault? If whole standardization process wasn't so slow, people would be using more unprefixed versions. And now, they are writing heated articles and signing petitions instead of solving this whole mess. The number of solutions were already proposed, versioning, -alfa- -beta- prefixes…
The way I see it, browsers in androids and ioses are new IE6. They have advantage of being bundled with os, they implement their own -webkit- features, nobody else can use. Something should be done about that.
And about the tools, they cure only the symptoms of a bigger problem, that is, writing same code 5 times to have it work in all browsers is realy bad, bad idea
I've tried SASS and LESS and have stopped using them.
95% of the time I've found them to take longer than just writing the CSS. I feel like it took away from learning/writing CSS. You'd either have to learn the CSS3 and the mix-in or you could just not learn the CSS3…but that just seems wrong.
What's the disadvantage of just assigning all of border radius stuff to a class and using that class where you want it? Seems like we're accomplishing roughly the same thing as using a mix-in, just without the variable.
If we're relying on a preprocessor for CSS, what's next…A preprocessor for HTML and another for JS?
I agree with all that, my thoughts are summarized in these two points.
Developers should stop coding vendor prefixes by hand.
Vendors shouldn’t add any more prefixes into production releases.
@Jeffrey Way
(…) and Compass is oriented programation (for programmers), CSS is mainly reserved to designers.
@Peter Gasston
Yeah good one. The gradient angle is a good example of a semantic change that introduced no breaking syntax.
@Peter Gasston
Actually, a 45deg gradient goes exactly the same direction in both versions of the spec. ;)
@Andy VanWagoner
Sass's job isn't to fix prefixes – but it does provide you the tools with which to fix it to your liking. You can write your own mixins to do it exactly how you would like, in a pretty succinct and easy fashion.
Compass, on the other hand, as what you might actually mean to reference, does the best it can and takes an approach via Chris's opinions. To go back to what I said about Sass – if you don't like his approach you can either write your own mixin that takes precedence over his (you can even wrap your own around his own mixin) or you can write straight up css in the context of Scss files.
@Jeffrey Way
"I'm a huge Sass fan, but the reason why I've never fully invested in Compass is because there's a certain amount of memorization required. I can't always remember what these mixin names are called. We need to make this task as simple as humanly possible for people…or they, by and large, ignore these tools."
I can't wrap my head around this as the practice of software development leans on memorization of esoteric syntax on the regular.
If you can remember the myriad css properties and their vendor-prefix'd mutations how is it that the memorization of a few calls to the compass library is too much? I keep references to a half dozen languages open a day because of your point – I can't remember everything either. Compass gets close – it's not perfectly in line with the proposed syntax, as paul has mentioned – but that's fine. I think the Sass and Compass team have done a pretty good job getting the right docs in the hands of the people using it daily.
@Mazz
"What's the disadvantage of just assigning all of border radius stuff to a class and using that class where you want it? Seems like we're accomplishing roughly the same thing as using a mix-in, just without the variable."
There is no disadvantage. In fact, there's a good advantage to doing it that way – keeps the css file sizes down. And you CAN do this with sass using the @extend method — http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#extend — this way keeps the classes out of your markup and provides you with a nice OO-like manner in maintaining your css.
"If we're relying on a preprocessor for CSS, what's next…A preprocessor for HTML and another for JS?"
HTML – meh, not really. But there is HAML. FWIW … not a fan.
JS? Most definitely :D –> http://coffeescript.org/
@Joel
Agreed.
Oooh, dangerous article. Well done though, and I agree. Prefixes aren't and never have been the best way to do things. Too late now though. . .
Completely agree with the fact that stable browsers should have zero support for prefixed properties.
@Michael If you're looking at something like less, you could use the Less App (for mac) or Win Less (for windows) to compile things for you. Combine that with elements, you'll have some pretty solid css3mazingness prefixed support.
I totally agree, but the cat's out of the bag now so it's yet another thing that we have to live with. I tell my students that knowing how to cope with all the variations is why they are about to worth so much in the work force.
BTW http://css3generator.com/ puts the prefixed versions before the standard one
Hi Paul,
I must confess I'm a bit skeptical about tools like Compass.
I mean, just take a look at the generated CSS of Compass's site… ugliest shit ever and a lot of unnecessary repeated styling.
The only thing I can accept, in order to don't loose my mind with IE, is using CSS3Pie, everything else, even with prefixes I do prefer to write pure CSS on my own.
But, as always great article! :)
@Bruno Couto
Nicholas Gallagher took the outputted content of Bootstrap's less stuff and then redid it, handcrafting all the styles. The result was code that was 5% bigger after gzipping.
You run your javascript through closure compiler or uglify; it's not pretty or readable, but it is small, which is important. The code you ship to production *should* be ugly. If it's pretty, you're doing your users a disservice
@Paul Irish
Ok, against evidence I can't argue. The code I ship for production is never pretty, since it's always minified, but I'm pretty sure I could do the styling of Compass's site smaller then it is actually.
Anyway I'm giving Compass a try to check it on my own :)
All your articles are very informative Thanks
Well I gotta say SASS can come in pretty handy when prefixes get in the way of front-end coding bliss. Love those @mixins and @extends. Before I digress with SASS junk Ill get back to the point of prefixes.
Its been pretty gut wrenching to see CSS3 gradients syntax ping pong while the other shiny toys you mentioned make it through squeaky clean. What a verbose error prone mess gradients began as. I am Still trying to reason with myself (yes we chat from time to time) why I still prefix for box-shadow. Did text-shadow ever have a prefix? If it did I never used it, but I use border-radius prefixes still. Why? I have no idea. I think Im sceered.
Prefixes are a pain in the ass when the time comes to clean up. We need a better way, we need better, better, better
Well I gotta say SASS can come in pretty handy when prefixes get in the way of front-end coding bliss. Love those @mixins and @extends. Before I digress with SASS junk Ill get back to the point of prefixes.
Its been pretty gut wrenching to see CSS3 gradients syntax ping pong while the other shiny toys you mentioned make it through squeaky clean. What a verbose error prone mess gradients began as. I am Still trying to reason with myself (yes we chat from time to time) why I still prefix for box-shadow. Did text-shadow ever have a prefix? If it did I never used it, but I use border-radius prefixes still. Why? I have no idea. I think Im sceered.
Prefixes are a pain in the ass when the time comes to clean up. We need a better way, we need better, better, better
Great article Paul!