Why use specific vendor prefixes instead of one representing all browsers
As far as I know, the only reason for using vendor prefixes is because the browser developers submitted the new specification before it is fully implemented according to the W3C
But why do we need a specific vendor prefix for each 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 can't it be written like
.box{
-vendor-box-shadow:0 0 1px #000;
box-shadow:0 0 1px #000;
}
each individual browser -vendor-
implements differently when viewing the prefix . This not only makes it easier for developers but also for browser makers as situations like microsoft and opera with compromise started to be supported -webkit-
because developers were lazy to use -ms-
and -o-
never promoted. If this was the case with -vendor-
, this applies to all browsers.
Can anyone shed some light on this?
source to share
As far as I know, the only reason for using vendor prefixes is because the browser developers submitted the new specification before it is fully implemented according to the W3C
Not; according to the W3C, the purpose of a vendor prefix is to provide a vendor with its own implementation of an experimental, proprietary, or other non-standard feature. The prefix is intended to identify the specific vendor responsible for this implementation. From the CSS2.1 spec :
In CSS, identifiers can start with '-' (dash) or '_' (underscore). Key words and property names beginning with - 'or' _ are reserved for vendor-specific extensions. Such vendor-specific extensions must be in one of the following formats:
'-' + vendor identifier + '-' + meaningful name '_' + vendor identifier + '-' + meaningful name
For example, if organization XYZ added a property to describe the border color on the east side of a display, they might call it -xyz-border-east-color.
In fact, the specification does not even mention "experimental implementations of existing or pending standards," although this still falls under the category of "non-standard".
Also, since a provider can implement their own property however they like, you cannot guarantee that every provider agrees on something as simple as the property's syntax. 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 into the final specification that Mozilla had to follow when they bypassed the ads border-radius
to the standard in Firefox 4. But here's the kicker: The reason Mozilla originally implemented longhands with old names is because once, these were the names used in the specification ! So not only did WebKit rename the properties, but also the CSSWG, which ultimately led to incompatibilities between implementations.
It doesn't make much sense to have one prefix for all experimental implementations, because then you could just force everyone to implement the property without the prefix and keep having to duplicate it or "unprefix" it later. And even then, you still have the aforementioned issue of evolving standards and implementation incompatibilities.
The problem with WebKit prefixes simply stems from widespread abuse of prefixes by both vendors and authors (basically, authors prefer to use only -webkit-
and ignore others due to the popularity of Chrome and whatnot). Browser vendors have found a much better way to deal with this, which allows them to ditch prefixes altogether , like hiding experimental properties behind compatibility flags in their interface.
Note that prefixes are still used for their original purpose; for example, Microsoft uses -ms-
various WinRT components to implement CSS, and Mozilla uses -moz-
XUL to implement CSS, which is used to implement the Firefox user interface.
source to share
Vendor prefixes are not implemented in the same way, some of them take different parameters or in a different order, like gradients. In this case, you won't be able to write a generic -vendor-gradient because they don't take the same parameters.
In the vendor prefix list, 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 for a 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 the options are different, another example I remember is the content justification when I used flex items:
justify-content: space-between;
-moz-justify-content: space-between;
-ms-flex-pack: justify;
-webkit-justify-content: space-between;
Here you can see that for the -ms-parameter and the properties are different to achieve the same result.
Vendors have their own implementation, so they cannot be generalized.
source to share