Microsoft begs Web devs not to make WebKit the new IE6(arstechnica.com)
arstechnica.com
Microsoft begs Web devs not to make WebKit the new IE6
http://arstechnica.com/information-technology/2012/11/microsoft-begs-web-devs-not-to-make-webkit-the-new-ie6/
14 comments
To complete the circle of irony, it seems that some of the developers who were the loudest to shout about standards-compliant web design and development when IE held the reigns are now guilty of much the same thing - the number of sites (and indeed blogs that either implicitly or explicitly state the same) that seem to have been designed with a "Looks great in Safari on my Mac, my iPad and my iPhone, ship it".
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.
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.
> standards-compliant web design
I persist in misreading this as standards-complaint web design.
I persist in misreading this as standards-complaint web design.
Ignoring the evidence you read little more than the title, the doublethink required to produce this comment staggers belief. The "darkest days of IE6's reign" was a direct result of Internet Explorer from about IE4 onwards beating the pants out of Netscape on technical excellence (ironically in this context, including CSS support), a situation that Chrome in particular is now well on its way to repeating.
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..
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..
So IE's short-lived superiority negates the many many subsequent years that followed (the dark days) in which it was a stinking dead weight around the neck of every web developer on the planet?
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.
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.
>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.
In fairness, that appears to be what ars is saying, not what MS is saying.
In fairness, that appears to be what ars is saying, not what MS is saying.
You have to actually read the article, because it's a little different than the (kinda linkbaity) title implies.
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.
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.
I'm waiting for the people writing the CSS and HTML standards to do something like be more proactive about approving extensions so we don't need the -webkit garbage in front of rules.
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 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.
Can you imagine the size of the CSS spec if any old brainless mutt could add to it on a few weeks' notice for the past 15 years? At which point, creating a fresh browser implementation quickly becomes insurmountable.
I never said that they'd all be approved. Surely an extension request from someone the committee had never heard of would be rejected, but from the WebKit or Mozilla crew they would give it consideration.
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.
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.
Creating a fresh browser implementation is pretty much already insurmountable! The last time anyone major implemented a browser from scratch (at least in a major sense) was Mozilla in the late 90s: everyone since has just built on previous work, as even though people may hate design decisions (that made sense a decade ago!) the cost of starting again is too high.
Adding a TLD requires a single DNS entry. Adding a CSS property requires a full specification of how it behaves and interacts with the rest of the CSS model. The former is simple, the latter is hard.
The main problem is the CSS prefixes. Since features under them might be different, they need to exist separately, but developers tend to use them even if they aren't fully standardised yet.
The problem discussed here isn't the use of CSS prefixed properties -- it's the use of ONLY CSS prefixed properties. Include prefixed properties and the official properties and when browsers drop the prefixes everyone is happy.
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.
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.
Reminds of people using "standard compliance" when "boat anchor" is meant.
These are two very different scenarios.
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.
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.
Agreed on all points, and to add another: Webkit is in use by more than one competitor. There are the occasional shootouts between Chrome and Safari to be obvious, and so long as both wish to be preferred by their users, they'll both continue to innovate or, at the very least, prevent the stagnation that IE6 became.
> Webkit is in use by more than one competitor.
As was IE6: maxthon and some other browsers used IE6's engine. And Maxthon users loved it because it was innovating.
As was IE6: maxthon and some other browsers used IE6's engine. And Maxthon users loved it because it was innovating.
Browser shells don't count. We're talking rendering engine here. Trident (IE6's engine) was fully controlled by Microsoft and until Chrome Frame came out (and promptly not adopted at all) there was no way to change the rendering engine in Internet Explorer.
As r00fus mentioned, I think that's giving Maxthon a little more credit than deserved. The 'core' of IE6 was still IE6, and adding a bunch of fluff around it didn't change that. As such, the IE6 engine, the thing that mattered, went untouched.
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.
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.
Front end developers should be including unprefixed declarations along with the prefixed. That's common knowledge.
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?
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?
You know what? Most browsers are developed pretty much entirely in line with the agile manifesto; most have either quick releases or a permanently stable master branch (to use git parlance!).
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.
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.
Isn't that a bit like saying don't make Linux a monopoly? Things are a lot better with an open source "monopoly" than a proprietary one. In fact I'd say an open source monopoly is even preferable.
Not at all. It's saying use standards when there is a standards compliant alternative, because it's both better coding practice and because it means you won't be screwing over your users and you won't be screwing over developers who wish to write alternative implementations.
Gecko is also open source, and the same Webkit-only mindset that breaks new Trident (IE10) and Presto (Opera) also breaks Gecko (Firefox).
Did anyone actually bother to read the blog post[1] linked in the ars article? Nowhere does Microsoft "beg" anyone to do anything, and in fact IE6 is isn't even mentioned. Glad to see everyone is jumping on the anti-Microsoft gravy train though.
[1] http://blogs.windows.com/windows_phone/b/wpdev/archive/2012/...
[1] http://blogs.windows.com/windows_phone/b/wpdev/archive/2012/...
This sounds like a PR stunt.
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.
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.
I was able to gather the following links which may be interesting:
* 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.
* 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.
Don't worry Microsoft, there is a version of chrome that runs inside internet explorer without special privileges.
Problem solved.
Problem solved.
Uh, not on the mobile. They're talking about Windows Phone 8, which has a derivative of IE10 running on that phone OS.
Man, I hear all this about not leaning on Webkit, and I would actually like to try a Windows Phone for a while, but remembering that it has IE just sends shudders down my web developer spine.
I wonder if they ever considered adopting webkit for IE. Is there any reason not to? Apart from MS pride.
The main reason IE doesn't adopt webkit is that IE's current purpose is to provide stability and backwards compatibility to enterprise customers. A large portion of corporations have custom built webapps to provide basic services like HR, Payroll, etc. and they rely on IE to provide consistent behavior for these services.
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)
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)
You can still use Webkit without requiring your browser to be bleeding edge. You can still update at the same glacial pace that IE has updated by using Webkit, shaking all the bugs out of it, and then releasing it.
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.
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.
They could provide trident so corporations can safely live in IE6 world until they die or grow up and webkit by the default for rest of the users.
It was sort of mentioned. Mozilla, Opera, and Microsoft all brought up that as being something they may be "pressured into" doing.
http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.h...
"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.
http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.h...
"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.
Sure would be nice to get IE10 support into Zepto.js. IE support is one of the main reasons we continue to use Jquery Mobile, but Zepto would meet our needs (with a bit of re-work) at a much smaller download size.
[deleted]
This is SO NOT like that in A LOT of ways.
Why can't they just use Webkit then everyone will be happy.
There are, believe it or not, things that IE does better than WebKit. For instance, IE uses Direct2D (essentially the state of the art for vector graphics) for rendering.
Yet it doesn't use WebGL (essentially the state of the art for hardware-accelerated cross-platform three dimensional rendering in the browser).
Sure, there are lots and lots of things that WebKit does better than IE. I'm just pointing out that it's a tradeoff; it's not cut and dry in favor of WebKit.
They can rewrite the renderer in D2D.
Though I somewhat agree, having moz and ms using separate rendering engines does provide some opportunity for innovation.
because khtml is shit
And I beg Microsoft to make it easier for me to test on IE- release IE for OSX.
You can download a free VM that runs on OSX to test.
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.