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?
[ Parent
| on HN ]
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.