They do happen to incidentally be right that we should try to adhere to the standards but to compare the state of WebKit today to the darkest days of IE6's reign is pure chutzpah.
For one (unnamed example), I recently built a launch page with a service that purports to do just that, provide a landing page of the "Coming Soon" variety, the ability to customize some links, provide some metrics, etc, and give your users a single page as a placeholder.
The interface for this design - and more importantly the resultant page for end users - is utterly horrific, largely unusable in Firefox, Chrome and IE10.
I persist in misreading this as standards-complaint web design.
As for whether Chrome or Safari are 'better' in some way than Microsoft of yesteryear, both companies have an attitude toward backwards compatibility that could at best be described as 'disposable', particularly in the case of Google. In the meantime, Chrome is pushing a new 'open source' version of ActiveX on the world (NaCl), and extended the web specs so much that they've all but plain given up on cooperation with the W3C in favour of their own kangaroo court (WHATWG). I could go on..
The only double-think and belief staggering in play here is the idea that a rapidly evolving, open-source and highly standard compliant modern browser (Chrome) is anything like IE at any point in its history except perhaps the present day.
In fairness, that appears to be what ars is saying, not what MS is saying.
The root issue isn't about market share, it's about writing browser-specific code. That was a bad idea in 2002, and it's an even worse idea in 2012 now that we have the benefit of history and are so many polyfills.
Writing --webkit-only code doesn't stick it to the man, it sticks it to the web ecosystem that we all swim in. I had long and frustrating arguments a decade ago with web developers who enjoyed writing IE-only code because they were upset about a Netscape bug they'd hit last month. They were sticking it to... everyone, a few years later.
Bottom line: if you're a professional web developer, act like it.
It should be as simple as filling out a form requesting a property and getting it within a matter of weeks at the outside.
If you can apply for ".poop" as a top-level domain name, there's no excuse for not having a CSS registry.
It would help break up the formalization process into smaller components.
Even then, until it's absorbed into the standard there's no obligation to implement that property. It would just mean you could be assured that if your proposal did make it into the standard, you would already be using the correct name.
Well, unless their initial implementation was non-standard. But even if that is the case, if you don't update your CSS, including the non-prefixed property won't hurt your design more than leaving it out will.
Developers never had a chance to help IE grow. IE stagnated because it was locked up and Microsoft was happy with it's state.
Webkit is open and being worked on by many people in many different places. Webkit can grow with help from outside of itself. IE could not.
As was IE6: maxthon and some other browsers used IE6's engine. And Maxthon users loved it because it was innovating.
That isn't to say that Maxthon wasn't awesome, it was. But it also wasn't nearly as pervasive as even Safari is really.
But the real issue here is how damn long it takes for declarations to become standard... border-radius is just now reaching that point and how long has it been?
And sure there are plenty of historical cases backing up how long these things take, but we should be out of that now. We use git. We're agile. We iterate. Why don't the folks making the browsers, and more so, the folks making the rules catch up?
The issue isn't in shipping browsers which support unprefixed properties, the issue is:
- Dropping prefixed forms (which is basically not happening in WebKit, as Apple is scared of breaking non-web content, and they have no way to tell who is using WebKit within an application for bundled content and who is using it for the web) which means web developers have no encouragement to move to the prefixed forms.
- The convoluted specification of CSS which means people frequently find bizarre, bad interactions with other parts of the specification which people want to work out before shipping.
- The inability to drop anything once shipped: once something is shipped in a web browser, sites often start relying upon it (even if it isn't interoperable, behind UA-sniffing), which makes it hard to drop (users don't like sites breaking, and most applications need users to have a viable business model), and hence makes a lot of pressure to get it right first time, giving very little space to iterate.
- W3C policies which care about the patent policy and having a stable specification everyone can implement perfectly than about continual iteration.
Un-prefixed declarations are everywhere. They're part of every framework, and what every developer tries first. Then comes -webkit, -o, -moz. IE hacks are far more widespread. filter?
I've been looking for sites without un-prefixed declarations for an hour and come up short. If there is any merit to this, I'd love to hear it.
* IRC log of W3's meeting, where Mozilla, Opera, and Microsoft bring up the possibility of being forced to support -webkit prefixes: http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.h...
* Article on Opera and -webkit prefix adoption: http://www.netmagazine.com/news/opera-confirms-webkit-prefix...
* Mozilla's analysis of -webkit usage on the web: https://bugzilla.mozilla.org/show_bug.cgi?id=708406 There's a lot of data there. Raw data is here: https://bug708406.bugzilla.mozilla.org/attachment.cgi?id=601... . Some processed data in a spreadsheet: https://bugzilla.mozilla.org/attachment.cgi?id=599084 . You may want to view others as well.
I haven't personally looked for sites that do this, but I use Firefox and have a Windows Phone, and in both cases I have found that I've ran into sites that were either Chrome only or simply looked terrible in my browser, not because of technical limitations, but because the developers had really only tested on Chrome. In some cases, I've ended up spoofing Chrome's UA in Firefox and found that sites still worked.
If IE wants to stick around it needs to come up to HTML5 standard, not drag everyone else down to their level.
Should they update their apps? Probably, but it costs money to build systems like that and most corporations don't want to drop money on something that already works perfectly fine.
Adopting webkit would completely disrupt all of these services, and Microsoft would basically destroy its customer base/relations.
Alternatively, Chrome is about pushing the boundaries of what's possible on the web. It's great for new companies, startups, and small developers, but as they move fast and implement new standards / functionality they also break stuff, and unlike Microsoft it doesn't really matter to the webkit dev team if a certain medium size corporation's old payroll app no longer works because of the latest chrome update.
Different browsers serve different purposes, and IE's is to provide stability. Hence they don't adopt webkit.
(I was an intern with IE this past summer and I asked the very same question minus the last part to my manager, and this was his response)
There is no requirement that it be exactly like Chrome. Look at Safari on OS X, that Webkit engine is not the same one that goes into Chrome. By the time that Safari is released Chrome is already several Webkit versions ahead.
"Discussed problem of WebKit monopoly on mobile and the consequent pressure for other engines to implement -webkit- properties."
For IE on WP7, Microsoft originally planned to support -webkit-text-size-adjust: http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascri... , but later decided not to.