[paulirish]

This is a good thing, and there is basically no way around it.

There is a varying degree of a WebKit monoculture on mobile. Without great site compatibility, users will never successfully switch to a non-webkit browser, but currently much of the great mobile content out there assumes webkit prefixes and userAgent. So Opera, Mozilla, and MS basically need to adopt some of the mobile webkit properties in order to get compatibility, in order to get users. It's either that or advocacy wherein we try to get every site ever to not publish with just WebKit prefixes. But in reality, this advocacy effort has been underway already for over two years and we're still in this bad situation.

Look at the chart linked to from http://paulirish.com/2012/vendor-prefixes-are-not-developer-... When IE10 comes out (or it's complementary mobile browser), less than 25% of all sites that use CSS transitions will have them working in IE10.

Vendor prefixes are bad for us as developers and they're bad for browsers because it leads to situations like these. We'd be in a better situation without them.

BTW, one detail that wasn't really covered: I believe this change is localized to Opera's mobile browsers. Their desktop story is, I think, unchanged.

(All the above is a personal opinion and not that of my employer, yadda yadda)

[MatthewPhillips]

Is vendor prefixing really worse than UA sniffing Paul? Your employer is one of the worst offenders of the latter (not blaming you). Maps, for example, falls back to a very primitive version in Firefox Mobile despite it being perfectly capable of rendering the more advanced site.

My attitude is that if you don't want to test on anything other than Safari Mobile and Android Browser then fine, don't test, but let the site degrade gracefully or not on other browsers.

[politician]

> don't test, but let the site degrade gracefully

In practice, graceful degradation requires testing.

[MatthewPhillips]

I chose the wrong words, my meaning was that they should allow non-WebKit browsers the chance to render the site and if they fail, they fail. Forwarding the browser to another URL because you whitelist only a couple of UAs is a bad bad idea.

[alexchamberlain]

What would happen in the situation that a browser has developed a non-prefixed property, which later becomes a standard, but with different functionality?

[paulirish]

Prior art of vendor features that were introduced sans prefix: innerHTML, XMLHttpRequest, <canvas>, querySelectorAll, innerText...

We've done this before and handled it fine. In JavaScript you can test the features, in CSS you end up duplicating a few lines of CSS-- see the gradients example: http://paulirish.com/2012/vendor-prefixes-are-not-developer-...

[MatthewPhillips]

Dropping vendor prefixes entirely is a bad idea. The syntax for gradients has been revised a couple of times. Without vendor prefixes you'd have to pick which version to support, back when different browsers had different implementations.

Same is true now of IndexedDB.

[alexchamberlain]

I would prefer the following 2 pronged approach: * First, prefixed properties in nightlies/dev versions of browsers, such as Canary. This would allow testing, without imposing a specific standard. Once a proposal is written, implement it without a prefix in the normal way. * Second, we need a tool to update our CSS files automagically. I should be able to use the non-prefixed version and the prefixed version added by the tool. Apache, Nginx should have an extension which does this automatically and could easily be implemented by CDNs.

[paulirish]

I like this as well. Browsers are considering not shipping prefixed properties to their stable channels currently.