3 ms·

Why the fuck did anyone ever think vendor prefixes are a good idea? If you want to prefix, prefix with versions. I should be able to type `-beta-mask-image: u

Why the fuck did anyone ever think vendor prefixes are a good idea? If you want to prefix, prefix with versions. I should be able to type `-beta-mask-image: url()` and any browser that implements that version of the spec can pick it up. There's no good reason to have to type the same exact thing 3 times to target each browser engine.

joshuacc 12y ago
Because the vendors sometimes proposed incompatible variants of the same feature before it was standardized. And they would implement it behind their individual prefixes so that you could experiment with both the IE and FF variants, for example.
- bsimpson 12y ago
  If you don't implement the same spec, bump the version. This is not a complicated idea. Instead of -webkit-mask-image and -moz-mask-image, have -beta-mask-image and -gamma-mask-image. When IE comes along and wants to play with WebKit's implementation, they implement -beta-mask-image and all the sites that use it get IE support for free.
  - adrianpike 12y ago
    They did. -moz and -webkit and -ms and -o. Unless we're actively working in synchrony, your "beta" won't be my "beta".
beejiu 12y ago
It's better than typing one thing and it doing 3 different things in 3 different browsers.
- phkahler 12y ago
  No, that just shifts the burden onto every website instead of onto the few browsers. If they render differently someone needs to fix their browser rather than everyone has to build sites that work both ways.
  - eropple 12y ago
    And when two competing interpretations of an unfinished standard exist, with different semantics because they have not yet been finalized?
gtjrossi 12y 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/ https://air.mozilla.org/web-compatibility-summit-talks/ (Starts around 31 minutes into the video) [1] http://caniuse.com/#feat=css-gradients http://caniuse.com/#feat=css-gradients [2] https://www.chromestatus.com/metrics/css/timeline/popularity/197 https://www.chromestatus.com/metrics/css/timeline/popularity...

joshuacc 12y ago

Because the vendors sometimes proposed incompatible variants of the same feature before it was standardized. And they would implement it behind their individual prefixes so that you could experiment with both the IE and FF variants, for example.

bsimpson 12y ago
If you don't implement the same spec, bump the version. This is not a complicated idea. Instead of -webkit-mask-image and -moz-mask-image, have -beta-mask-image and -gamma-mask-image. When IE comes along and wants to play with WebKit's implementation, they implement -beta-mask-image and all the sites that use it get IE support for free.
- adrianpike 12y ago
  They did. -moz and -webkit and -ms and -o. Unless we're actively working in synchrony, your "beta" won't be my "beta".

beejiu 12y ago

It's better than typing one thing and it doing 3 different things in 3 different browsers.

phkahler 12y ago
No, that just shifts the burden onto every website instead of onto the few browsers. If they render differently someone needs to fix their browser rather than everyone has to build sites that work both ways.
- eropple 12y ago
  And when two competing interpretations of an unfinished standard exist, with different semantics because they have not yet been finalized?

gtjrossi 12y 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/ https://air.mozilla.org/web-compatibility-summit-talks/ (Starts around 31 minutes into the video) [1] http://caniuse.com/#feat=css-gradients http://caniuse.com/#feat=css-gradients [2] https://www.chromestatus.com/metrics/css/timeline/popularity/197 https://www.chromestatus.com/metrics/css/timeline/popularity...