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.

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.

They did.

-moz and -webkit and -ms and -o.

Unless we're actively working in synchrony, your "beta" won't be my "beta".

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

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

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.

And when two competing interpretations of an unfinished standard exist, with different semantics because they have not yet been finalized?