I have already said a lot of what I want to say about vendor prefixes, but here’s one more tidbit.

Removing support for prefixed CSS features, when a feature is considered stable, seems counterproductive to me. Here’s why.

Supposedly, the entire point of vendor prefixes for CSS is that it allows multiple browser vendors to experiment with a new CSS feature, before it is stabilized through the standardization process.

This assumes that it is possible we are using a different syntax for -moz- than we would for -webkit- or -ie- or -o-.

If not, then what is the point of bloating our CSS code with mutiple lines of code for each vendor?

If developers are using non-standardized CSS features, using vendor prefixes, then current best practice is to also include the unprefixed attribute in the same declaration.

Why would this possibly be a good idea?

If you are using vendor prefixes, then by definition that feature has not yet been standardized. There is not yet a syntax that has been decided will stand the test of time. In fact, there could be two mutually incompatible syntaxes for each vendor prefix, as there was in gradients. That is the entire point of vendor prefixes.

So.

If two browsers may have different syntaxes, why would you just pick one syntax to use in an unprefixed declaration before that syntax has been standardized?

And if vendor A comes up with a new feature that will be going through the standardization process, and vendor B has not yet implemented that feature, why would you want to make sure that you include all of the possible vendor syntaxes, as well as the unprefixed declaration, when that feature has not yet been standardized, and the syntaxes could vary in other vendor implementations as well as the final standardized implementation?

To do so, in my opinion, could result in the strong possibility that if the standardization differs from the original vendor implementation, code will break.

But, ah, developers should just go back and fix all of their code, once the feature has been standardized!

That ignores the way most websites are developed. A site is developed. It is tested. The client approves. It is launched. Hooray!

And there the code sites, until the next redesign rolls around again.

Is that the way all sites are developed? No. Would it be wonderful if all sites were developed with perpetual maintenance contracts, so that CSS and HTML could constantly be revised when the W3C changes or standardizes how things function? Well, maybe, but it would make the web more expensive.

Or should we just say that developers should not use any attributes that have not yet reached candidate recommendation. Thus, they will never have to go back and fix code. At the pace that the W3C establishes new standards, that means we would have an awfully long-time to use much-needed technology.

So.

Do we use vendor prefixes as they were intended, to use the actual syntaxes that each vendor is developing for their browsers, so they can experiment and come up with the best possible implementation? If we do, and we do not include an unprefixed version, and then when the unprefixed version is standardized, support is dropped for prefixed versions (as Mozilla is doing right now in Firefox for box-shadow), then sites without the unprefixed feature will no longer display that feature.

Or do we simply make sure we use every single vendor prefix for every single unstandardized feature, and do we also include an unprefixed version so that when that feature is standardized, that feature continues to display on our sites, without any changes necessary on our part? The danger there is that this will not work if vendors experiment with different syntaxes and the standardized version of the feature differs from the prefixed version.

This conundrum is why vendor prefixes are a mess.

With many features, this might not be a problem. If everybody agrees from the get-go on the proper syntax for a feature, wonderful. The current best practices module, of using all vendor prefixes plus an unprefixed declaration, should work fine. It’s the outliers that are troubling.

The best solution I see for this is to just get rid of vendor prefixes altogether, and use a -v1-, -v2-, -v3-, as I previously detailed. That would allow vendors to all jump on the bandwagon of a particular version of a proposed feature, or try a new version. Other vendors could support any of the proposed syntaxes. And as long as vendors continued to support the various proposed versions into the future, the web wouldn’t break upon standardization. You don’t start using the standardized version until it is standardized. And everything just works fine and dandy for all.

The trouble would be that browsers would need to support multiple versions of a feature, perhaps indefinitely, which would bloat their rendering code. And developers would need to still include the versioned feature declarations into the future if they wanted it to work in older browsers, also bloating code.

So there are problems with that method, too.

I have come to the end of this rant, without any firm conclusions. Let’s carry on the conversation in the comments.

There has to be a better way.