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

But jokes aside…

Truth is: It’s not the W3C failing here, it’s the browser vendors.

People will simply start ignoring proposed standards if “they don’t work”… meaning: “when browser vendors fail to support them correctly”. I don’t have to reach back far into my memory to remember the XHTML 2.0 fiasco and what gave reason to create what is now called HTML5 (you know, that smart HTML2 excuse of “it’s new but looks as messy and familiar like it’s 1996″).

There was and is no reason to abandon any standard or technology… unless you are a browser vendor and want to trim down your investments into human resources.

Dropping XML and other (already proposed) standards or even splitting up the W3C to focus on smaller pieces of the cake doesn’t solve anything… browser vendors hiring more people to make their browsers support the proposed standards will – but then they would have to invest hard cash. Killing standards by not supporting them is much cheaper. And that’s where capitalism bites it’s own tail while trying to suck the life out of the internet.

When you write “SVG can be saved, but only if it re-charters to drop all XML dependencies in the next version.” I have to work hard not to laugh, as it shows the lack of understanding what SVG actually is and where it came from. But hey, I understand the problems of a browser vendor working with SVG in a sluggish HTML5 document. Tsss… it’s as if browser vendors said: let’s kick out XHTML and forgot that it’s more than just a webpage.

Looking into the future, I could as well say that plain text files saved in little TXT files is probably the most future-proof technology, so why bother having a W3C at all. When browser vendors finally managed to kill all standards, we could go back to setting up our own BBS systems again and abuse the internet (which is nothing more than a network) as a phone-line like back in 1993. But wait… where would Google be by then? Oh right, they would have killed their own internet and your efforts for the Crome Browser would void themselves.

My two cents: it’s easy to press the delete button on stuff, but “easy” isn’t always the best way to do things.

And before I go, I would like to remind you of your own writings, which contradict this rather “one-sided” article: [quot] “My goal is to make the web suck less and to the extent that I can keep politics and economics from creeping in, that’s what this blog is about.” [/quot] Question: why am I not the only one seeing you are letting too much “politics” and “economics” creeping into this article? Maybe it’s time to remember the roots… or it’s time to change that “about” text. Contradictions never manage to convince.

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.

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.