Why do browser vendors make their own css properti

问题:

• Why do browser vendors make their own css properties, even they know these properties will not pass the w3c validation before approved and added by w3c?
• What is the purpose? Is for their own testing, or for web developers, or to demonstrate browser capabilities to the world and to the W3C organizations and to CSS development team of W3C?
• is it like a beta version of demonstration?
• if i use any browser specific for now can they remove that property's support from future versions.will i have to edit my css in future

For example:

https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions

回答1:

• Responsible browser vendors (the big ones, excluding IE), know what the web will look a few years later. I don't know where you get the "not pass" part. They only implement things the browsers will support in a few years
• It's about giving the tools to design the web for modern and future browsers.
• Yeah, we can say it's a beta.
• Yes and no, it's unlikely they will remove support for the extensions part.

What the W3C is thinking about is the syntaxis. Let's take gradient for an example:

-webkit-gradient(
    linear,
    left bottom,
    left top,
    color-stop(0.2, rgb(86,45,199)),
    color-stop(0.6, rgb(112,72,239))
)
-moz-linear-gradient(
    center bottom,
    rgb(86,45,199) 20%,
    rgb(112,72,239) 60%
)

Both these codes generate the same gradient. As you can see, there's no standard procedure, the syntaxis is both confusing and different for webkit and mozilla based browsers.

But let's imagine in two or three years, the implementation is done. Now you just have to add another line of code for the standard.

gradient: center bottom #colorFrom opacityFrom #colorTo opacityTo;

Now both engines will understand the gradient statment and if it's specified after the extension ones, this last one will be the one to interpret.

回答2:

The standards process doesn’t run like this:

1. Spec is written
2. Browsers implement spec
3. Everything is ponies and rainbows

Like any IT project, the spec is written, then bits of it are implemented, then the spec is changed based on lessons learned during implementation. It’s a delicate dance, as Robert O’Callahan said.

Doing initial implementations with vendor prefixes means that if the spec is changed later, existing code written against the existing implementations won’t break.

Vendor prefixes also allow browser-makers to experiment just for the heck of it, which can result is quite nice things like Safari’s gradients.

回答3:

they are mostly work-in-progress from for example css2->css3, but since a browser doesn't yet support it (like css3), it is exposed with different names.

回答4:

They do it for several reasons:

1. As you've said, demonstrate unique browser capabilities
2. Expose certain browser behaviors - think of those properties as an API
3. Create stickiness - once you have a lot of code relying on proprietary properties, you're "bound" to the browser.

And yes, sadly those properties may change or even disappear in future versions, necessitating code changes. Bottom line: stick to standards, or at least be aware that any current shiny feature has a future price.

回答5:

mozilla has extensions which are likely to be in the next css standard just to be one step ahead. when these properties will be standard, use them without the moz prefix, in order to support more than just one browser.

回答6:

I'm not privy to the specifics of the CSS standards evolution, one can guess that following are the main reasons for manufacturers to "draw outside of the lines" of the standards.

• Standard drafting is a long, slow process (often for good reasons), and this pace is not satisfactory in a fast changing, heated competitive environment.
• Sometimes this is a way to showcase potential new features, for the purpose of either confirming their validity or of pressuring the standardization body to include them retro-actively.

While effectively circumventing the established standardization process, the above drivers are probably well meaning and mindful of the greater good. There are unfortunately less noble reasons:

• For the manufacturers who have a critical mass of the market, this provides the opportunity of making the product somewhat compliant but with extra features, and such features can then be used as a way to make it difficult for users and/or developpers to switch (hence both ensure user fidelity and possibly providing incentives for other users to try their product, hence further increasing their market share.)
• For manufacturers with a weak market position, this can be a way of doing the same. As such manufactuers feel they have but little to win (or to save) by sticking strictly with the standard, they attempt to invent a new feature and lead with it.