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 -webkit-opacity, -moz-opacity, -o-opacity and 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
A -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: -webkit-gradient versus -moz-linear-gradient and -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.
Conversation
Seems like IE migrated their User Agent String team to the CSS team. ._."
When will they stop making such idiotic decisions.
@arnout: why is it an idiotic decision? An argument would be helpful
I can see the MS team meeting: "Guys, we need to support this CSS3 property in IE, it's already being used by Webkit.", says the manager.
A developer says, "Why don't we just piggy back on that, it's not changed since being implemented and is used all over the place. If we can take advantage of that we may get some good will from developers who won't have to re-code their sites to suit IE Mobile."
"Excellent, two birds with one stone" says the manager - and the deal is done.
To the general public and most web developers (NB: not those who read www-style) they won't notice the difference and may even like it. I don't endorse it but I completely understand why they've done it.
I know of at least one occasion where this happened, yes: Webkit's Transitions changed syntax when specifying multiple properties to transition. That broke implementations I was building—fortunately I discovered it prior to things going live, but I have a couple of direct channels to the Webkit team which most people don't and thus can't rely on.
There was a brief moment (which I unfortunately can't seem to find on the Web right now) wherein it was announced that Firefox would start to implement CSS Transitions using the -webkit- prefix. That concerned me then just as this concerns me now, because it means I can't differentiate as a web developer anymore. In the case of Transitions, Webkit has a relatively stable implementation by now (finally); Firefox's is far from stable, complete and robust—if they were still using the -webkit- prefix I would be forced to rely on really bad practices (like
userAgentsniffing) in order to do the right thing. It's precisely the kind of situation we want to avoid on the web.I understand Microsoft's desire to implement both prefix syntaxes, so that they can offer the result of the feature to users of Windows Phone 7 without forcing all web developers to update their code, but the problem with that is, like Firefox and -webkit-transition, it's a browser vendor breaking their own rules to fix someone else's problem.
If we don't like writing this:
…then we should create solutions that alleviate that problem for us, like a server-side script that takes care of this (I've been thinking of writing an open-source Django plugin for this exact reason, actually). It shouldn't be resolved by browser vendors abusing the vendor prefix system in order to make websites slightly better in their newest browser: that's the whole user agent mess all over again.
I mean, are we really happy that we have a UA that is something like this?
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us) AppleWebKit/531.22.7 (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7Because I sure as hell don't, and I would prefer we don't go down that road again.
The problem of an implementation being changed when a new version of a browser comes out is inherent in the fact that we are playing with effects that do not have a fixed specification. If they break then they break - and it's our choice as developers whether we use the -vendor- "work in progress" or not. We shold not expect them to be stable, and if we do that is our own misunderstanding of the situation.
But it's a much worse situation and one (more importantly) that is impossible to fix if vendors start cross-vendor parsing and then only one vendor changes its rendering implementation and the others don't. You end up with two or more implementations of a common idea and no control over who gets what. Vendor prefixes are designed to give that control, that is their point. A vendor prefix should NEVER be rendered by a different vendor, no matter how simple the syntax or how unlikely it is to change. Wait until it's tested thoroughly, and part of the W3C spec. Then you parse it cross vendor.
Adding multiple "identical" declarations is a small price to pay for guaranteed control and stability whilst also getting to play with new-fangled shiny.
Syntax DOES change. Look at the -moz-gradient vs -webkit-gradient syntax's to see how there are differences, and multiple ways to skin a cat. Which is better? We don't know until we try them, and cross-pollination is entirely possible. If a browser supports both vendor prefixes then we get into the VERY sticky area of rule precedence. If I write both, which does MS parse? the -ms- rule or the -webkit- rule? Should it prefer its native, or go on order dependence? What if the -ms- shorthand property has an effect that the -webkit- one doesn't? Should that effect still render?
How can order dependence even work? If IE is rendering the page and sees -ie- and then -moz- what happens if the implementations differ?
In short, it's a hell of a mess, and the IE team are only parsing -webkit- stuff to leapfrog proper development and get results fast because -webkit- is in the wild and -ms- isn't. It is a terrible *idea*.
In this instance, it's not going to effect much - but it does legitimise the abuse of the -vendor- prefix and set the industry up for a shambles later down the line if it continues to be applied.
Last week I suggested -css3 prefix for all the browser "Can we all get along" . In my opinion it doesn't matter if it is -css3 or -beta it is important that all browsers communicate and find one prefix and after they all should use the same syntax.
We are in the front of great danger (much bigger than IE6) if all browser can Not find the way to communicate. The result will be you will have different CSS for different browsers.
If we have 100 different browsers we will have 100 different CSS. I think nobody wants that.
Vladimir, no, they should not embrace one prefix. Multiple prefixes support exploration and that is happening.
Microsoft's apparent piggybacking on Webkit is odd. Can anyone confirm that is in fact what they're doing?
OK, so I design a site that uses:
-webkit-foo: xxx;
-webkit-bar: xxx;
These two style rules create a nice effect. I also take care that the absence of both rules is just as usable.
The problem now comes when a non-webkit browser decides to support -webkit-foo, but not -webkit-bar. I now have a situation I didn't plan for ...
It's messy, it's wrong.
I think that the probably reason why Microsoft resorted to such an action is because they realized that a majority of developers of mobile websites have been "ignoring" non-webkit browsers.
With Blackberries sporting a webkit browser that means that a very large percentage of mobile-internet users will be using a webkit-based browser.
It's very common for me to go across a site's CSS and find that the front-end-dev only implement the vendor prefix tags.
Bottom line: yes, it is a bit "cheap" that Microsoft is implementing another vendor's prefix in mobile IE, to get sites to render better on it, but I honestly think that they wouldn't have done it if the devs hadn't forgotten about the future of specification, and other browsers.
Microsoft is doing this to remain competitive.
@Jen: http://blogs.msdn.com/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx is the post where IE team say they're parsing -webkit-
Vladimir - that's wrong. Remember the point of these tools is NOT to be relied upon, they are all experimental and not supposed to be used for production in a "risk free" manner. They are the little proto-entities that have yet to grow up into a fully fledged specification. Single prefixes rendered by multiple engines are a terrible idea. Prefixes exist to facilitiate trials of possible implementations - they aren't about giving you finished toys to play with. If they get to the point where they are reliable and all vendors agree it's logical, then they graduate to W3C approved CSS. Not before.
Jon,
All your notes are great points. I do hate using vendor prefixes too, but at some point they help me to change layout depending on a browser, e.g. I can have rollover for an image with -moz-outline-radius since FF supports round outlines and Webkit doesn't, so I can make unique rollover for Webkit too. Well, it against CSS specification when all properties should be standardized.
I wonder what will happen if I'll use both properties on the same object, e.g.
.class {
-webkit-text-size-adjust: 200%;
-ms-text-size-adjust: 100%;
}
Which one has "more power"? Is -webkit- prefix only an alias in IE browser or it is independent property on its own?
Personally, I don't think that I will either develop nor optimize my sites for IE mobile, but I am 100% sure that after this Jon's article Microsoft IE Team will not use this property at all.
I agree with Marco & Matt. I understand why MS is doing this. Way too many developers use only webkit prefixes, with no fallback to the standard - which BTW should be LAST in the cascade!
Way too many developers have Webkit up their arse, to paraphrase PPK. I regularly see code with Webkit only prefixes, even for stuff that's been in Firefox long before it came to Webkit!
Still, that is no excuse for MS. This is a bad move that will not alleviate the problem, but make it worse, since now developers are EXCUSED if they do not provide anything but the Webkit prefixes.
Some people really need to stop complaining about having to write duplicate code. That's your job! If you don't like it, stop using experimental features.
webkit-text-size-adjust probably isn't a big deal. But by that same token, if that specific property isn't a big deal, why do they need to parse it?
It's arrogant of Microsoft to say that their implementation will match the Webkit implementation exactly. I don't think they've earned that level of trust yet.
I see this as organic growth of CSS. If Company A thinks it has a good idea, then Company A can implement its own extension to the wild and see if or how web developers and designers use it. If this extension becomes very widely adopted (even if it hasn't gone through the W3C) the browser market should be free to implement it. Isn't this how we got XMLHttpRequest?
@Jen & @Matt: I'm aware that everything is in experimental stage, but people are starting to like the new browser "experiments". There are many blogs and sites that are using CSS3 syntah. I think it is Ok to use the new CSS3 features. So everyone who is using CSS3 is using the browser prefix.
Even with prefix the syntah is different in some cases. Also there are browser who in some cases they don't use prefix... There are so many open issues.
In other words today we don't have standards. Looks like the History will repeat itself. We will continue to write for the browsers like we always did in the past. I'm already starting to miss the "good all days" when we only had to write for two browsers IE and Netscape.
@vladimir : I hear you, but the browser developers can change the implementation if they so desire. Sure, many things are pretty stable, but others are still being tinkered with (I probably shouldn't use the word tinker as it belittles what they do!). And they may have something great develop if they are given the freedom.
"We've also added support for the -webkit-text-size-adjust CSS selector. This selector allows you to control how text on the Web page is scaled to increase readability for the user (you can also use -ms-text-size-adjust, IE Mobile recognizes both)."
This seems weird. IE should just say that it supports the webkit selector and leave it at that. Naming it with their own prefix and saying that will work is definitely fishy. Webkit should implement something that tests to see if it is IE Mobile and then throw an error — no! :) That would only impact the end user and they don't deserve the insult. Lousy action on the part of the IE Mobile team.
It would be great if some of them would weigh in on this discussion. C'mon, Jon & Faruk, don't you know anyone you can ping? :)
@ Vladimir
"I think it is Ok to use the new CSS3 features" - then use them. No one is advocating you stop using them. But don't begrudge having to re-declare the effect for each vendor you want to support. That's the price we pay for getting to use this stuff before it's final. We don't have any rights to expect cross vendor conformance on experimental properties, nor can we expect the vendors to agree on how to parse and implement such an experimental feature when there isn't a spec for it.
@Carl - spot on. But you implement the NON vendor prefixed version, or if it's not been accepted into the W3C yet then you roll your own prefix. You don't hijack someone else's prefix - because if you do you can very easily break the web.
Sorry Jonathan, I don't mean to be tearing your position up but this did make me do a double take the second time through:
"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"
Why do we need a real world example to back it up? If the logic is sound then it's sound. I don't need a real world car crash to point to as evidence for a logic flaw possibly being fatal.
Marco, I'm remixing your comment for comparison (this isn't a criticism of your comment):
I think that the probably reason why Microsoft resorted to such an action is because they realized that a majority of developers of websites have been "ignoring" non-Netscape browsers.
With Netscape sporting a Mozilla browser that means that a very large percentage of internet users will be using a Mozilla-based browser.
It's very common for me to go across a site's markup and find that the front-end-dev implements Netscape-specific tags.
Bottom line: yes, it is a bit "cheap" that Microsoft is implementing another vendor's User Agent String in IE, to get sites to render better on it, but I honestly think that they wouldn't have done it if the devs hadn't forgotten about the future of specification, and other browsers.
Microsoft is doing this to remain competitive.
-- 15+ years. Same Microsoft. No difference.
Hi everyone,
We've decided against adding support for the -webkit- prefix after hearing everyone's feedback.
Thanks to all who weighed in on the issue. We've posted a follow-up on the IE Mobile blog for all who are interested.
By the way, Opera supports "opacity" now, they dropped the -o-opacity. Same goes for the border-radius. Only Mozilla and Webkit do this, which is silly. It's no different than the IE filters and transitions.
Nice work Joe, and thanks for listening and having a good sense of humour too :)
http://blogs.msdn.com/iemobile/archive/2010/05/11/update-css-and-js-support-in-ie-mobile-for-windows-phone-7.aspx
Thanks Matt. Proof positive that we do listen...
Isn't there a big risk of large-market browsers stagnating innovation of smaller browsers by doing this? An example:
I think it's just bad form to do that.
Completely offtopic, but is the software used on this website open source?
I think it's getting out of control. I agree with Ryan Cannon on this. If it goes on like this, there will be so many prefixes for so many controls (border radius, opacity etc.), that designers won't be able to keep track of them soon tbh.
I'm just hoping that browsers will sometime start to obey basic css3 selectors all-together without the webkits, so that 10 years from now we won't have another case of IE6.
I thought the point of standardization was to eliminate the need for -webkit-X and -moz-X why cant I just type X and it works in all browsers... MS should just quit the browser game and stick to making crappy OS's....
How far away are we from having browsers that are effectively media-types. Maintaining 5+ CSS files sounds daunting. Then again, if that were the case at least some reasonable group could take hold, let us write ONE, then it would be interpreted in to the other five, and ... wait.
This is a nightmare.
come on people.. are you still use IE?