Vendor interactions with the CSS working group and product secrecy
The minutes from yesterday's CSSWG face-to-face meeting are a very interesting read in all sorts of ways. I was somewhat struck by this part:
tantek: I think if you're working on open standards, you should propose
your features before you implement them and discuss that here.
smfr: We can't do that.
sylvaing: We can't do that either.
Those are the Apple and Microsoft representatives replying to Tantek.
Now I won't claim that Mozilla always does this, or that it's even always desirable; it's often better to have a prototype and then discuss the standard than discuss standardization in a completely theoretical way. But this is not about prototypes; this is about not being able to talk about a feature until there's a more or less complete implementation, which is when Microsoft and Apple tend to announce new features. I knew that both Microsoft and Apple had longstanding policies of refusing to discuss future plans, but hadn't really thought about the negative effect this blanket policy has on standardization efforts...
Posted by bzbarsky at February 7, 2012 1:50 PM
Right now, the way the ecosystem works with vendor prefixes, the likes of Google and Apple are being effectively rewarded by _not_ pushing to standardize their vendor prefixed properties. That is, under the current vendor prefix agreement, the technological advances made under the vendor prefixes are not accessible to other vendors/browsers. While that makes sense for experimental features with an evolving spec that risks changing very often, the intentions of vendor prefix is being abused when vendors refuse to move to standardize properties.
And the reality is that they have a huge reason not to do so: vendors can rig the field in their favors. If Google and Apple would speak honestly, they would probably say "why would we change anything? changing things would be against our interests."
Creating a whitelist of specific vendor prefixed properties that can be implemented by other vendors would effectively but an end to this vicious “collateral damage”, remove the reward, and ultimately, if this comes hand-in-hand with an awareness campaign, could result in tangible moves toward standardized properties.
A whitelist agreed and managed by a group of vendors would probably be a good way to move forward to insure things are not derailing and for standardization (versus penetration) to still be the ultimate goal for new properties.
The war over IE6 was won in big part by building overall better products which pushed migration of users out of IE6. While the same can’t really be done in the iOS ecosystem (thanks to Apple’s decision to block 3rd party browser engines on its platform), it can be achieved on Android. Leveling the playing field by agreeing on a whitelist of -webkit- properties - alongside building a kick-ass mobile browser - might be enough to secure enough of a market share and change the way things are done on mobile.
Blah, random disorganized thoughts. Wish everyone the best possible future we can shape for ourselves : )
The possible downside of a vendor prefix properties whitelist is that other vendors will be at the "mercy" of the original vendor and that vendor could change spec with the intention of harming other vendors parsing that vendor's prefixed property.
That said, it'd most probably not happen as playing with spec (for no other reason than harming competitors) would also mean unjustified messing up of web developers CSS code.
The good of a jointly managed vendor prefixed properties whitelist appears to outweigh the bad. And it seems to avoid the ugly :)