Why use specific vendor prefixes instead of one re

问题:

As far as I know the only reason behind usage of vendor prefixes is that they were introduced by browser creators to release a new specification before its completely implemented according to W3C

But why need a specific vendor prefix for every browser.

If we look at the following css:

.box{
   -webkit-box-shadow:0 0 1px #000;
   -moz-box-shadow:0 0 1px #000;
   -o-box-shadow:0 0 1px #000;
   box-shadow:0 0 1px #000;
}

why cant this be writted like this

.box{
   -vendor-box-shadow:0 0 1px #000;
   box-shadow:0 0 1px #000;
}

each individual browser on seeing the prefix -vendor- implements in its own way. This not only makes it easy for developers but also for browser creators as situations like microsoft and opera compromized started supporting -webkit- because developers were lazy to use -ms- and -o- would never rise. If it was the case with -vendor- it applies to every browser.

Can anyone throw some light on this?

回答1:

As far as I know the only reason behind usage of vendor prefixes is that they were introduced by browser creators to release a new specification before its completely implemented according to W3C

No; according to W3C, the purpose of a vendor prefix is for a vendor to provide their own implementation of an experimental, proprietary, or otherwise non-standard feature. The prefix is meant to identify the specific vendor responsible for this implementation. From the CSS2.1 spec:

In CSS, identifiers may begin with '-' (dash) or '_' (underscore). Keywords and property names beginning with -' or '_' are reserved for vendor-specific extensions. Such vendor-specific extensions should have one of the following formats:

'-' + vendor identifier + '-' + meaningful name
'_' + vendor identifier + '-' + meaningful name

For example, if XYZ organization added a property to describe the color of the border on the East side of the display, they might call it -xyz-border-east-color.

In fact, the spec doesn't even specifically mention "experimental implementations of existing or pending standards", although that just falls under the category of "non-standard" anyway.

Furthermore, because a vendor can implement their own property however they like, you cannot guarantee that every vendor will agree upon something as simple as the syntax of a property. For example, the longhand properties for border-radius looked like this in Firefox:

-moz-border-radius-topleft
-moz-border-radius-topright
-moz-border-radius-bottomleft
-moz-border-radius-bottomleft

Which is very different from WebKit:

-webkit-border-top-left-radius
-webkit-border-top-right-radius
-webkit-border-bottom-left-radius
-webkit-border-bottom-right-radius

As you can guess, the WebKit form was the one that made it to the final spec, which Mozilla had to follow when they got around to promoting border-radius to standard in Firefox 4. But here's the kicker: the reason Mozilla originally implemented the longhands with the old names is because once upon a time, those were the names that were used by the spec! So it wasn't just WebKit that renamed the properties, but the CSSWG as well, which ultimately led to an incompatibility between implementations.

There isn't much of a point in having a single prefix for all experimental implementations, because then you might as well just have everyone implement the property without the prefix and save having to needlessly duplicate it or "unprefix" it later. And even then, you still have the aforementioned problem of evolving standards and implementation incompatibilities.

The problem with WebKit prefixes simply stems from a widespread abuse of prefixes by both vendors and authors (mostly with authors choosing to only use -webkit- and ignoring others thanks to the popularity of Chrome and whatnot). Browser vendors have found a much better way to deal with this which allows them to abandon prefixes altogether, such as hiding experimental properties behind compatibility flags in their UI.

Note that prefixes are still used for their original intended purpose; for example Microsoft uses -ms- for CSS implementations of various WinRT components, and Mozilla uses -moz- for CSS implementations of XUL, which is used to implement Firefox's UI.

回答2:

Vendor prefixes are not implemented the same way, there are some of them that take different parameters or in different order, such as gradients. In that case you won't be able to write a general -vendor-gradient because they don't take the same parameters.

In the list of vendor prefixes you have,

• Android: -webkit-
• Chrome: -webkit-
• Firefox: -moz-
• Internet Explorer: -ms-
• iOS: -webkit-
• Opera: -o-
• Safari: -webkit-

UPDATE: I used a gradient generator and the output was this for some specific gradient

background: #1e5799; /* Old browsers */
background: -moz-linear-gradient(top,  #1e5799 0%, #2989d8 50%, #207cca 51%, #7db9e8 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#1e5799), color-stop(50%,#2989d8), color-stop(51%,#207cca), color-stop(100%,#7db9e8)); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* IE10+ */
background: linear-gradient(to bottom,  #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* W3C */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#1e5799', endColorstr='#7db9e8',GradientType=0 ); /* IE6-9 */

You can see that parameters are different, other example I remember is content justify when I used flex elements:

justify-content: space-between;
-moz-justify-content: space-between;
-ms-flex-pack: justify;
-webkit-justify-content: space-between;

There you can see that for -ms- vendor parameter and property is different to achieve the same result.

Vendors have their own different implementation, so they can't be generalized.