Re:Opera confirms support for WebKit vendor prefixes
by MatthewPhillips on Wednesday April 25, 2012 @01:01PM
(#3889926)
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.
Re:Opera confirms support for WebKit vendor prefixes
by politician on Wednesday April 25, 2012 @02:37PM
(#3890399)
> don't test, but let the site degrade gracefully
In practice, graceful degradation requires testing.
Re:Opera confirms support for WebKit vendor prefixes
by MatthewPhillips on Wednesday April 25, 2012 @02:55PM
(#3890468)
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.
Re:Opera confirms support for WebKit vendor prefixes
by alexchamberlain on Wednesday April 25, 2012 @01:09PM
(#3889970)
What would happen in the situation that a browser has developed a non-prefixed property, which later becomes a standard, but with different functionality?
Re:Opera confirms support for WebKit vendor prefixes
by paulirish on Wednesday April 25, 2012 @01:15PM
(#3890007)
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-...
Re:Opera confirms support for WebKit vendor prefixes
by MatthewPhillips on Wednesday April 25, 2012 @01:42PM
(#3890151)
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.
Re:Opera confirms support for WebKit vendor prefixes
by alexchamberlain on Wednesday April 25, 2012 @02:16PM
(#3890305)
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.
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)