Vendors using Competing Prefixes
IE Mobile for Windows Phone 7 has decided to implement support for
-webkit-text-size-adjust. They'll also be adding their own duplicate vendor-specific prefix,
-ms-text-size-adjust. That's right, Microsoft will be adding support for another vendor's non-standard implementation.
Is this good or bad? The general consensus on Twitter would indicate that this is a bad thing but while there is a scenario where this could go terribly wrong, I haven't found a real world example to back it up.
So why is this a bad thing?
Vendor-prefixed implementations may change
The point of a vendor prefix is to avoid a situation where an implementation changes before becoming a standard, thereby breaking all sites that come before it. This is a good thing. A vendor can continue to revise the syntax under a prefixed property without breaking things when they finally do become standard and implementations drop the vendor prefix.
If a competing vendor implements a vendor prefix, they run the risk that changes to the competing browser will then break their implementation. For example, if Webkit changes how
-webkit-text-size-adjust works then Microsoft will be in a tough situation because their implementation will break. The problem is, any developer who implemented
-webkit-text-side-adjust before the change will also find their implementations broken in newer versions of the browser.
Has there been a situation where a browser has changed the syntax on a vendor-prefixed property that has broken previous implementations? I can't think of any but feel free to chime in on the comments.
Of note, browsers have implemented syntax changes on non-prefixed properties like background that have broken previous implementations. Multiple backgrounds, for example, break on browsers that don't support it, requiring the background property to be specified twice. (The situation is exacerbated by the fact that vendor-prefixed properties in multiple backgrounds will be ignored in other browsers, requiring backgrounds to be specified three or four separate times to support all current browsers.)
Mimicking another vendor's prefix is like using no prefix at all
This argument is a misdirection and not the case at all. If every browser implemented a single vendor's prefixed property then the property would become standard and the prefix would be dropped. For example, imagine
-moz-opacity was implemented by all browsers before becoming standard. The property becomes
opacity and we all move on. I'd prefer this over
opacity all having to be set.
It's perfectly possible for all browsers to agree on an implementation using a prefixed property before re-implementing it with a non-prefixed standards-based property. The simpler the syntax, the easier it is to expect that the implementation won't change. The
-webkit-text-size-adjust property is a perfect example of this. It's very simple and extremely unlikely that the implementation will change.
Implementations may change but syntax won't
Sometimes browsers don't get the implementation correct. Border radius is a prime example of this. Firefox 2, for example, had a problem with their implementation that caused the rounding to be unbalanced. (I recall Happy Cog having an issue with this when working on the WordPress admin a couple years back; I can't find the article, though.) Had another browser implemented it like Firefox, the implementations would no longer match.
This situation is a little different because of expectations. In this case, the implementation had a bug. This wasn't a style preference or syntax issue. It was a bug in how a particular edge case was rendered.
Border-radius implementations across all browsers still don't match the specification in a lot of edge cases (something that IE9 is looking to address; my apologies if Opera has already done this in 10.5).
This is a grey area and I can see good points and bad points against this. The question is whether a feature is implemented by a web developer based on the expectation set forth by these edge cases. For example, if I expected all browsers to overlap border corners to compound transparency values then I'd be terribly disappointed when this started to get fixed in subsequent implementations.
In this last case, how does one browser mimicking the implementation of another change this situation? I'm not sure it does.
It's like -beta prefixes and that's bad
-beta prefix had been bandied about on the W3C style list where browser developers and the public at large discuss CSS implementations. The problem with the
-beta prefix is that it prevents versioning of a particular feature. Right now, vendor prefixes essentially act as a versioning process. One browser implements it using Syntax A. That's version 1. Other browsers ponder it and implement it using Syntax B. That's version 2. The vendor prefixes for each browser acts as the versioning system.
In the case of something like CSS gradients, browsers have implemented different vendor prefixes:
-moz-radial-gradient. The syntax may be different but so is the property name which essentially means that they are two separate implementations. Microsoft could theoretically implement both syntaxes and still not break anything.
Theoretically and hypothetically speaking
We often argue based on extremes to prove a point but the practicality of the matter is that this particular implementation of the
-webkit-text-size-adjust property in IE Mobile isn't really a big deal and is unlikely to affect developers to any extent.