|
|
|
|
|
by gtjrossi
4125 days ago
|
|
It was most often not the case that (a) vendor prefixed APIs matched a particular "version" of a spec nor (b) were interoperable across browsers at any point (e.g. -moz-foo didn't necessarily have the same behavior as -webkit-foo). The issue isn't vendor versus version prefixes. The issue is sites using early versions of an API, relying on them, and then never removing/upgrading that code. -webkit-border-radius for example doesn't necessarily match a particular version of a spec. Unprefixed, standard border-radius has been in all the browsers for several years [1]. Yet over 60% of page views (according to Chrome data [2]) still requires this property. So other browsers are forced to support the webkit version of this property for compatibility, which may not have a particular version of a spec for those browsers to reference when implementing support. If you're interested, I gave a talk with other browsers at Mozilla HQ last week about some new ideas for how we can further improve the strategy for experimental APIs going forward. Check it out and give me feedback if you'd like (@jacobrossi on twitter). https://air.mozilla.org/web-compatibility-summit-talks/
(Starts around 31 minutes into the video) [1] http://caniuse.com/#feat=css-gradients
[2] https://www.chromestatus.com/metrics/css/timeline/popularity... |
|