+1 Yehuda Katz

Btw, copying 4 lines for every rounded corner? Everyone uses LESS now right?

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”.

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.

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.

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.

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.

“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.

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.

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.

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

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.