Hacker News new | ask | show | jobs
by alexchamberlain 5161 days ago
What would happen in the situation that a browser has developed a non-prefixed property, which later becomes a standard, but with different functionality?
1 comments

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

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.

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.
I like this as well. Browsers are considering not shipping prefixed properties to their stable channels currently.