Comments for Vendor Prefixes Are A Rousing Success
The WG can deal with situations like Animations and Transitions eventually. If Apple won't submit -webkit-text-size-adjust and a myriad other mobile features that benefit their platform, the WG could decide to standardize it for them which is doable but awkward on many levels; it really is the creator's responsibility to submit their work. Yet even if the WG did this, subsequent implementations will not derive any benefits from their -moz, -o or -ms work until enough content reflects their existence. The end result remains an inferior user experience for anyone who does not use iOS.
For some features -webkit is effectively no more than an inventor prefix. Maybe Mozilla, Opera and Microsoft should treat it as such and implement the feature using the exact same name? I think the web would be better off with some usable level of interop backing up a de facto standard than no interop and no standard.
Most importantly, a well-designed process is no different than a well-designed feature: it makes doing the right thing natural and easy; doing the wrong thing should take work. The prefix system makes it far too easy for authors, editors and implementors to do the wrong thing:
- For authors, it takes less work to couple your content to a single browser than to create cross-browser content! For careful developers who care about all browsers, copying/pasting the same value 4 times makes it completely natural to add an unprefixed version of the property; why on earth would a standard body mess with such a level of agreement?
- For implementors, it rewards first-movers and offers no incentives to standardize a successful feature
- For editors, decoupling the spec from implementations allows standards to diverge from deployed reality because "prefixed properties are not CSS yet".
No acceleration of the standardization pace will change the fact that misusing prefixes is essentially the path of least resistance for everyone.
That is to say: I think arguments about what prefixing would theoretically allow are entirely unconvincing if we haven't seen those things happen by now.
As for testing solving problems: What roc and bz said. Consider the time from 2007 until now. I.e. the period when iOS was out in the wild but Mango was not. When Web developers during that time added -webkit-text-size-adjust, how often did they also add -ms-text-size-adjust for future IE on Windows Phone? How many of them are promptly going back and adding it? If they don't and if IE on Windows Phone doesn't support the WebKit prefix, surely it means that users of IE on Windows Phone get a worse user experience than users of Mobile Safari on iOS. That's bad for users and bad for the competitiveness of IE on Windows Phone. Why shouldn't this stuff just start working in IE on Windows Phone like insertAdjacentHTML started working in WebKit as soon as WebKit implemented it?
IE on Windows Phone is facing a prefix barrier to entry that desktop Safari didn't have to face when entering the desktop IE-dominated market earlier.
@Ojan: Changing the W3C Process is harder than changing CSS WG policy or how vendors behave relative to CSS. That's why I think it makes sense to decouple prefixing from CR, do what makes sense about prefixing now and worry about recalibrating CR later.
@Yehuda: Part of the problem with knowing about risks is that Web developers are the ones that choose to take the risk but if the risk actualizes, users of other browsers and, by extension, the other browsers are the ones that suffer.
Most developers of mobile-focused Web sites, who test only on Webkit. This includes Google developers. When we've asked Google teams to change this behavior, they generally haven't. I'm surprised you're not aware of this.
"As for removing prefixes, this is about vendors just doing it, and quickly."
Webkit, and by extension Google, has a de facto policy of never removing support for prefixed features.
"My view is that vendors should be given at least as long as it took to get a standard finalized from the introduction of their prefixed version for the removal process to be complete."
The first vendor to introduce a prefixed feature usually benefits the least from browsers being allowed to drop prefixes. Your proposal adds an additional incentive for the first-moving vendor to delay standardization as long as possible.
Vendor prefixes are not and will never be a success for a simple reason: vendor prefixes are browser specific, but the internet is NOT browser specific. Therefore, no one really uses them frequently as they are (a) NOT STANDARDS and therefore (b) not worth "learning".
+1 Yehuda Katz
Btw, copying 4 lines for every rounded corner? Everyone uses LESS now right?
Yes, you are hurting the web because you START implementing features in your browser BEFORE taking time to send working drafts to the w3c.
How do you want the w3c to "keep up" if you send the draft after your own implementation? It's not possible. And by allowing authors to use the feature early, you just make the w3c discussion more difficult, because changes could "break compatibility with existing content".
If medical corporations were selling experimental drugs at large scale, they could maybe save lifes because they shipped early. But, clearly, it is not allowed today anymore because it has become clear that the risks are more important than the gains. When they are developing new drugs, there's firstly an experimental period in labs and with a small amount of people. It takes time, but is what has allowed us to have faith in the drugs we buy. To me, it seems we are in the same situation here: testing should be reserved to testers. Don't put the whole web at risk.
If you are not going to change your egoïstic attitude with experimental properties because it gives you the lead, please be decent and say it loudly. Don't find fake arguments.
While Chrome is doing good in quick updates, same cannot be said of Android browser or Mobile Safari, in their glacial pace to update. Again, would all browser vendors commit to deprecating legacy prefixes in as short a time period as possible (say within the next 3 versions?).
Lots of good stuff here but one note: I honestly never felt limited by W3C's 'amazingly drawn out process'. Quite frankly, I think that is a red herring. Specs have reached CR in a year in recent times. The only expensive step is test suite creation. That is not cheap but imo quite necessary in order to achieve interop (setting aside what kind of testcases are needed). Otherwise I don't see where you get the idea the process itself is so onerous, especially in the CSSWG.
Any big delays I have witnessed are 100% self-inflicted e.g. when half a spec has 4 implementations while the other half has zero and some heated debate is needed to agree the latter should move to the next level. Or when a widely implemented feature sits on top of a module that hasn't been updated for two years. Blaming process may be more polite than blaming people; I find bad judgment or plain mistakes have far more of an impact than any process. The hard part of course is that often, the quality of a judgment is only obvious in retrospect.
Thanks for that.
A couple of quick thoughts:
- Vendors can have an arbitrary number of turns around the wheel so long as each property value grammar is incompatible with the other. Else, the prefix can be extended to include a new name/version. This isn't one-per-vendor. Not sure why you assume it should be?
- I'm not assuming maintenance of sites. Only that fallbacks are tested at *some* point. Vendors dropping prefix support is the same as the fallback being invoked.
- Faster-moving browser upgrade cycles change the overall cost of the prefix dynamic. The challenge is going to be for the W3C to keep pace, but I have hope. Nobody wants to write things out 3 (or more) times and webdevs get to drop their use of prefixes based on *deployed browser population*, not spec status. Faster updates enable faster un-prefixing (among a bazillion other wonderful things).
Could work if the versions in the standard namespace are similarly incompatible, but it removes the ability to change your prefix (-ms-feature, -ms-next-feature, -ms-near-final-feature, etc.) as you iterate.
More to the point, you're not assuming that the deployed population of browsers all support the same right-hand-side syntax/semantics. That's a dis-incentive for vendors to disagree and therefore bad for the competition of ideas.
As a webdev, I want vendors to have their own opinions about how a feature should be exposed (if at all), not just to chase tail-lights or block on some WG scrum before trying things. I also want the argument settled quickly so that a winner emerges and we can all just drop all of the prefixes SRTL.
I agree about people vs. process. Part of what I was hoping to illuminate in this post (but failed to, it seems) is that it's all people all the way down. Giving those people better tools and a better framework that sets them up for success is what I hope we're all gunning for.
Browser monoculture FTW!
It's a little difficult to take your critique seriously. I'm not suggesting that the W3C should "keep up" in perhaps the sense you mean...no WG should ever be a gate-keeper for experimentation. Instead, I want to see the WG continue it's current fast-follower behavior which is primarily enabled by the vendors themselves attempting to throw the "we want to play nice, what do y'all think?" flag. How? By sending draft specs. It's emergent social behavior and the first step in writing insurance on the feature. But don't confuse that with asking permission.
As to your medical analogy, well, I think you've simply lost all attachment to any reasonable perspective and have become unhinged from the reality of CSS's reliable parsing algorithm. Hopefully you can find a way to be less angry some day.
Regards
I hope it doesn't hide the fact that more than 75% of the prefixed properties used on the web today are -webkit- ones and they have often no equivalent prefix for other browsers (meaning only webkit browsers can understand them, like in the old "IE-optimized" days).
If those properties are useful (which they usually are) but are used widely on the web using a -webkit- prefix, I have to conclude that either (1) they were not ready to be used in production,(2) webkit devs didn't gave enough time to other UA to understand and comment the spec before shipping in RTM or (3) the property is stable enough and should have shipped prefix-free.
In those cases, I don't see any other culprit for the prefix mess than the browser vendor that made misuse (intentionnaly or not) of them and has put other browser vendors and web authors in difficulty (using the webkit prefix or don't use the property).
To many, the response to this problem is simply to ship experimental properties in experimental builds only (with a prefix or not, I don't mind), and ships in RTM builds when either (1) the spec has reached a consensus or (2) the spec will never get a consensus anytime soon but the feature is considered as needed by the implementor.
Shipping in an RTM browser a prefixed property while the standardisation is in progress is a mistake. I would prefer an unprefixed property that support only cases that are known as stable enough.
And, by the way, I fully understand how, from a Ian Hickson Editor-In-Chief prospective, the W3C process is unbearable ('What do you mean I can't just go remove this element? I AM THE EDITOR!'). When worldviews and goals reach that level of opposition, one man's bug will be the other's feature.
I have no idea what the MTTPR would be. I also very much doubt it would mean anything if it were to compare massive documents like CSS2.1 with modules like CSS3 Color; or if it encompassed a period of time where the browser vendor with a 90% market share was peripherally involved when it wasn't outright absent. So while I do suspect the number would look horrible, there is such a cross-current of outlier inputs I very much doubt we could reach any useful conclusions about the W3C process.
So yes, it is about people. And there are many aspects to that broad category. One of which being that we may not have enough editors, for instance. While up to 30 people might seat around the table at a WG meeting these days, how many are active editors? Is that due to the nature of the process? Maybe. Having ownership and accountability without authority is something few people are really good at managing. The level of expertise and amount of time required are also barriers regardless of how light you make your process. Not everyone can spec things like CORS or Writing Modes. The tooling is not very easy or forgiving either. I think Community Groups indicate some of those issues are understood. There is more to do.
So the predictable and conveniently ill-defined swipes at the 'process' deserve some serious qualification to be helpful imo. I yet have to see standardization really harmed by process. I've seen it delayed by lack of consensus, unilateral editor decisions, spec neglect, low level of interest from implementors, feature creep or bloat, lack of testcases (we have modules that could be REC by now, but no test suite...) etc. The list goes on and on. Problems that can and do occur on many software projects, in fact. Pretending, even indirectly, that some process or methodology can magically fix them - or that the lack of either would - seems wishful and largely beside the point.
The very optimistic 1 year to CR is not at all good enough when certain features in the spec are stable much earlier. We should redesign the process so that stable features naturally go to CR within a couple months of being considered stable.
I made one such proposal here: http://lists.w3.org/Archives/Public/www-style/2011Nov/0338.html
What's more, following that brief flurry of commercially-driven innovation, what great iterative improvements have their prefixed nature enabled? Endless bike-shedding over the gradient syntax has simply resulted in Webkit now supporting two syntaxes, both of will be available in perpetuity because their is too much production content using the original to ever consider removing it. Minor fiddling aside, transforms, transitions and animations remain basically untouched since their original implementation.
Ever time I copy out a dozen identical, prefixed, properties, I curse the day the CSS WG decided on prefixing as a sensible approach. And I curse implementers like yourself who have the temerity to tell us they're for our own good, when they're manifestly for your own convenience, not in innovating, but simply in putting of the need to finish the specification and write a test suite.
90+% of developers of mobile sites. They all test in a single UA (WebKit) and move on. And since that UA actively encourages use of prefixes (pushing them extensively via developer documentation and so forth), this causes a good deal of harm to the web and to users, who end up being locked into a particular browser.
Now you may happen to not care about this and think it's not a problem, but the current situation with WebKit on Mobile is very similar to the situation with MSIE in 2000 or so, and just as bad.
"And how did we think we’d get a good standard, anyway? By sitting in a room in a conference center more often and thinking about it harder? Waiting on a handfull of early adopters to try something out in a tech demo and never stress it in practice? That’s not a market test (see: XHTML2), it doesn’t expose developers to the opportunities and tradeoffs that come with a new feature, and doesn’t do anything to address the inevitable need to integrate feedback at some point."
We cannot simply wait until "it's ready" to ship the features to real developers, because it does not expose the feature to enough real developers to learn valuable information.
I, personally, do not know any developer who thinks that using experimental features is risk-free. Experimental features have the same expectations as library code (may change, become deprecated, or removed entirely some day), and not the expectations of fully specified code.
Everybody needs to stop coddling those of us who build apps for a living, release features as available with the appropriate caveats, and iterate on them until we, together, arrive at a final, standardized solution.
Microsoft hasn't exactly been rushing to move these specifications, so complaining that, years later, there is wide deployment of a proprietary prefix for what essentially became a proprietary feature feels disingenuous to me.
Having brand-new, experimental and unvetted features land immediately without a prefix strikes me as irresponsible, but so does letting these features languish for years in the WG. Everyone's problems, mine included, would be addressed by a more rapid pace of standardization of new (especially mobile) features.