Dear Microsoft, please use WebKit(drawar.com)
drawar.com
Dear Microsoft, please use WebKit
http://www.drawar.com/articles/dear-microsoft-please-use-webkit/210/
25 comments
Agreed. Monoculture is always a poor situation to find yourself in. It's bad in agriculture, it's bad in politics, and it's bad in computing.
Not only does monoculture kill innovation and induce complacency on account of a lack of competition; it creates the perfect security conditions for malevolent exploitation. Imagine a security bug that is exploitable in 99% of the industry's web browsers. Yikes.
We are actually in the perfect position right now. Webkit (props to the original KHTML team) is receiving accolades by the heap and has put intense pressure on both Mozilla's Gecko and Microsoft's Trident teams. The result will be 3 very fast rendering engines (and if it suits them, they'll be standards compliant too).
Not only does monoculture kill innovation and induce complacency on account of a lack of competition; it creates the perfect security conditions for malevolent exploitation. Imagine a security bug that is exploitable in 99% of the industry's web browsers. Yikes.
We are actually in the perfect position right now. Webkit (props to the original KHTML team) is receiving accolades by the heap and has put intense pressure on both Mozilla's Gecko and Microsoft's Trident teams. The result will be 3 very fast rendering engines (and if it suits them, they'll be standards compliant too).
I don't think a monoculture has to be a bad thing when it's not backed by an associated monopoly. WebKit is used by Apple's Safari, Google's Chrome, and almost everybody's mobile browsers, but they all have different goals and requirements. They share code where it makes sense, but add to it their own GUIs and other innovations. Competition on the basis of performance is as healthy as ever, and the WebKit world has a lot going on in the way of new features and security.
I think that the benefits of standardization and code sharing have far outweighed the "monoculture" dangers for UNIX, and I see no reason why a similar balance between diversity and compatibility can't be achieved for web browsers.
I think that the benefits of standardization and code sharing have far outweighed the "monoculture" dangers for UNIX, and I see no reason why a similar balance between diversity and compatibility can't be achieved for web browsers.
At least with a dominant WebKit, everyone has access to the source code, and can either submit their improvements back to the core maintainers, or they can fork WebKit if the maintainers refuse to allow their improvements. With a dominant IE, you're at the mercy of some "unknown" Microsoft engineers/managers finding enough time in their schedule to implement those improvements.
How is that any better than an engine programmed by experts?
How is forking going to help us getting uniform display of the elements?
Seems to be working just fine for webkit already.
One of the things that IE is working on for IE9 along with Mozilla and Webkit is more rendering and layout-based tests, so when you specify things like "dotted line border", it will look identical in all browsers.
Things like this will serve the web better than "Hey everyone, let's all use Webkit".
Things like this will serve the web better than "Hey everyone, let's all use Webkit".
The thing people don't realize is that there is no standard WebKit browser, either.
http://www.quirksmode.org/webkit.html
So, even if MS did convert to webkit, which webkit?
http://www.quirksmode.org/webkit.html
So, even if MS did convert to webkit, which webkit?
microsoft should switch to webkit-ish.
This post is relevant to why this advice will not and should not be heeded: http://www.codinghorror.com/blog/2008/10/programming-is-hard...
In summary: "If it's a core business function -- do it yourself, no matter what."
Building runtimes (and a web browser is a runtime for web apps) is a core business function to Microsoft.
In summary: "If it's a core business function -- do it yourself, no matter what."
Building runtimes (and a web browser is a runtime for web apps) is a core business function to Microsoft.
This is an excellent point that I think is not mentioned enough in the open source world. This should especially ring true after the recent top link on Why The Lucky Stiff and his "digital suicide". If something is that important to your business, you'd be a fool not to hold on to it, and how are you going to do that if you don't own it yourself?
Yes, it is a pain to test pages in different browsers. But I would prefer to have competition in the browser front.
"When you don’t have to worry about the development of a rendering engine then you can focus on the actual browser. Google understood this with Chrome and it is fast climbing up the charts. I know that WebKit development is essentially controlled by Apple, but since it is open source who really cares?"
Actually, Google surpassed Apple in commits to the WebKit repository a few months ago. Google adopted WebKit with Chrome but by no means are they not worried about the rendering engine's development.
Actually, Google surpassed Apple in commits to the WebKit repository a few months ago. Google adopted WebKit with Chrome but by no means are they not worried about the rendering engine's development.
Apple tends to have a flurry of commits right before a new Safari is about to be released, or a new OS release is made. That is when Apple commits the latest and greatest they have to offer.
It will be interesting to see when this happens again.
It will be interesting to see when this happens again.
Curious - have there been any conflicts between Apple/Google on the direction WebKit is going? (e.g., Google implements a bunch of stuff in WebKit which ends up invalidating some work Apple was doing. Apple backs out the offending changes and checks in their stuff. etc. etc.)
> "In a perfect world Mozilla would adopt it as well, but I don't see that happening because they have too much invested in Gecko along with too many different projects using that particular engine. Maybe one day though."
Hasn't occurred to him that maybe MS also has invested too much in its rendering engine?
Hasn't occurred to him that maybe MS also has invested too much in its rendering engine?
"I’m tired because it’s 2010 and we are still dealing with the same issues that we thought we were solving with CSS back in 2002."
I don't know, maybe you weren't doing real work in this industry back then, but things are light years beyond what they were like in 2002. We've got JavaScript implementations that actually perform well. DOM works largely the same across browsers (remember that Layers debacle from Netscape? WTF). PNGs work properly. We have largely similar rendering across all browsers. I'm talking about things at least being in roughly the same place on the screen, having mostly the same styling, whereas you couldn't even count on things being in the same general location between browsers before.
"We are all working from the same W3C specs so why can’t we at least make everything render the same way."
Have you read the W3C spec? It defines a plethora of optional features and many key required features are ambiguously stated. In other words, it's a poorly written spec. What do you think is more likely, Microsoft intentionally breaking spec or the spec being poorly worded? Considering the differences between Gecko and WebKit that you yourself have also mentioned, I'm going with the common denominator here, the spec.
I don't know, maybe you weren't doing real work in this industry back then, but things are light years beyond what they were like in 2002. We've got JavaScript implementations that actually perform well. DOM works largely the same across browsers (remember that Layers debacle from Netscape? WTF). PNGs work properly. We have largely similar rendering across all browsers. I'm talking about things at least being in roughly the same place on the screen, having mostly the same styling, whereas you couldn't even count on things being in the same general location between browsers before.
"We are all working from the same W3C specs so why can’t we at least make everything render the same way."
Have you read the W3C spec? It defines a plethora of optional features and many key required features are ambiguously stated. In other words, it's a poorly written spec. What do you think is more likely, Microsoft intentionally breaking spec or the spec being poorly worded? Considering the differences between Gecko and WebKit that you yourself have also mentioned, I'm going with the common denominator here, the spec.
"What do you think is more likely, Microsoft intentionally breaking spec or the spec being poorly worded?"
Well, I'm waving my Bayesometer at both those propositions and both are coming up pretty close to 100%, within each other's needle wiggles. I don't think I can answer that.
(Oh, so close to a word coining: http://www.google.com/search?q=bayesometer )
Well, I'm waving my Bayesometer at both those propositions and both are coming up pretty close to 100%, within each other's needle wiggles. I don't think I can answer that.
(Oh, so close to a word coining: http://www.google.com/search?q=bayesometer )
Maybe I completely missed the point, but, why WebKit? Why is WebKit better? I mean, I could use the exact same arguments for Gecko, and even for the IE rendering engine. I mean, if everyone uses the IE rendering engine, it'll always look the same, but that wouldn't resolve all problems.
There is a theory which states that if we did adopt one rendering engine to rule them all, the healthy competition that keeps (most of) the various rendering engines innovating would collapse and progress would stall.
Eventually, some upstart would seize the opportunity by launching a new browser with a better rendering engine.
There is another theory which states that this has already happened.
Eventually, some upstart would seize the opportunity by launching a new browser with a better rendering engine.
There is another theory which states that this has already happened.
IE already CAN use webkit:
http://code.google.com/chrome/chromeframe/
Just gotta convince the users to install it.
But that's going to be way easier than convincing Microsoft to dump millions in invested development.
http://code.google.com/chrome/chromeframe/
Just gotta convince the users to install it.
But that's going to be way easier than convincing Microsoft to dump millions in invested development.
If you can't convince Mozilla to adopt WebKit, how can you expect MS to do the same? I really wish Mozilla and Opera adopted WebKit and devs from all the non-MS browsers worked together on WebKit. Then we'd have an IE and non-IE web. Right now, we have a IE vs FF vs Safari vs Chrome vs Opera web and it really really sucks as a developer.
The whole "develop for standards" doesn't work when each browser renders things slightly differently. While coding up http://bulletxt.zetabee.com I realized that each browser handles line-height, padding, margins, and font-alignment differently, especially when applied to textarea. Sure, most of the non-IE browsers handle things in a similar way but similar is not good enough in many instances. If I do margin-top: -4px, it works fine in Chrome and Safari but I need to make it -6px in Opera and -2px in Firefox. IE doesn't even work that way so I end up doing something completely different.
I would be completely fine with there being 1 rendering engine and 1 JS engine no matter the browser. And all browsers could improve on the speed/performance of these engines without changing the output or requiring different input. If I do padding-right:10px for a float:left element with position:fixed, I want it to look the exact same in ALL browsers.
I know standards try to do that but it just doesn't work. Standards work in theory but in practice, it is the code that works. WebKit works like WebKit. If I created the spec/standard based on WebKit and implemented it based on this new standard, it would NOT be WebKit. Standards work well for protocols and communication methods but for actually rendering arbitrarily complex window elements, they don't work and last decade of failed attempts at standardization have shown us that. Think of how many websites/tutorials/articles exist solely to help deal with browser inconsistencies. Now imagine if that effort could have been made towards something productive.
The whole "develop for standards" doesn't work when each browser renders things slightly differently. While coding up http://bulletxt.zetabee.com I realized that each browser handles line-height, padding, margins, and font-alignment differently, especially when applied to textarea. Sure, most of the non-IE browsers handle things in a similar way but similar is not good enough in many instances. If I do margin-top: -4px, it works fine in Chrome and Safari but I need to make it -6px in Opera and -2px in Firefox. IE doesn't even work that way so I end up doing something completely different.
I would be completely fine with there being 1 rendering engine and 1 JS engine no matter the browser. And all browsers could improve on the speed/performance of these engines without changing the output or requiring different input. If I do padding-right:10px for a float:left element with position:fixed, I want it to look the exact same in ALL browsers.
I know standards try to do that but it just doesn't work. Standards work in theory but in practice, it is the code that works. WebKit works like WebKit. If I created the spec/standard based on WebKit and implemented it based on this new standard, it would NOT be WebKit. Standards work well for protocols and communication methods but for actually rendering arbitrarily complex window elements, they don't work and last decade of failed attempts at standardization have shown us that. Think of how many websites/tutorials/articles exist solely to help deal with browser inconsistencies. Now imagine if that effort could have been made towards something productive.
I don't think there's anything inherently wrong with Gecko and I don't think Mozilla should drop it. It is still a quite advanced and fast rendering engine. I think the problems of Firefox are mostly management issues (being completely out of touch with the real needs of their users) which in turn effect which features get developed or which bugs get fixed.
About the rendering differences between Gecko and WebKit: a very tiny fraction of my time is spent on fixing things that look differently in Firefox and Gecko. Getting things working (and displaying properly) in IE is a lot bigger issue. I have yet to meet a rendering/JavaScript Gecko/WebKit difference issue that cannot be fixed trivially in a couple of seconds.
About the rendering differences between Gecko and WebKit: a very tiny fraction of my time is spent on fixing things that look differently in Firefox and Gecko. Getting things working (and displaying properly) in IE is a lot bigger issue. I have yet to meet a rendering/JavaScript Gecko/WebKit difference issue that cannot be fixed trivially in a couple of seconds.
??
Negative margin-top renders the same for me in every browser except IE6. This code renders a green rectangle border on top of its parent with negative margin-top even though it's inside:
#main{background:#F00;height:128px;width:128px;margin:100px;}
#shift{background:#0F0;height:16px;width:128px;margin-top:-16px;float:left;}
<div id="main">
<div id="shift"></div>
</div>
Maybe you should design your sites so that it doesn't need to render pixel-to-pixel the same as on the designers workstation.
I do that for most of my sites but there are many things that require pixel-level adjustments. If all I'm making is a blog with headers and p, span tags, nobody cares if things don't line up exactly the same on my browser vs. their browser. However, take a look at: http://bulletxt.zetabee.com/demo - not everything that is created using HTML/JS is a basic page. If you're trying to make even slightly complex web-apps, one extra pixel width will move things into the next line.
It's very easy to say "design for standards" or "design for fluid layouts" but when it comes to actually coding it up, it just doesn't work like that. My point wasn't that I don't know how to make things work. In the end, all my finished products work well. My point was that it's a pain to make everything work nicely across all the browsers and that inconsistency causes headaches.
It's very easy to say "design for standards" or "design for fluid layouts" but when it comes to actually coding it up, it just doesn't work like that. My point wasn't that I don't know how to make things work. In the end, all my finished products work well. My point was that it's a pain to make everything work nicely across all the browsers and that inconsistency causes headaches.
I miss the days the web was about content and people didn't expect accuracy down to the pixel in their HTML.
I wish it were this simple but it's not.
Most small and medium sized businesses still run at least one web applications that was written when IE had 90% of the market and which relies on Microsoft's backwards implementations.
I suspect Microsoft couldn't make Webkit backwards compatible to those apps if it wanted to. The trident code base probably has quirks Microsoft itself has completely forgotten about. But many small web based programs rely on those quirks to run.
Most small and medium sized businesses still run at least one web applications that was written when IE had 90% of the market and which relies on Microsoft's backwards implementations.
I suspect Microsoft couldn't make Webkit backwards compatible to those apps if it wanted to. The trident code base probably has quirks Microsoft itself has completely forgotten about. But many small web based programs rely on those quirks to run.
I can't believe it's nearly as common as it was 5 years ago. It's anecdotal, but all of the big IE-only industry-specific web apps I've had contact with have been rebuilt.
There certainly are some in the wild, but Microsoft doesn't need to have support for these old applications hold back progress. They certainly can (and do) have separate modes within the same browser, they could even run separate engines. They could also just distribute a separate "Legacy IE" application to support these apps.
But that's one of the many problems with Microsoft: they refuse to make hard decisions.
There certainly are some in the wild, but Microsoft doesn't need to have support for these old applications hold back progress. They certainly can (and do) have separate modes within the same browser, they could even run separate engines. They could also just distribute a separate "Legacy IE" application to support these apps.
But that's one of the many problems with Microsoft: they refuse to make hard decisions.
Microsoft should release a version of IE6 that can coexist with current browsers and break the compatibility chain. It would cut down on their testing and allow them to move forward.
The logic behind this is that the browser wars aren’t won by who can render HTML the best, browser wars are won by speed and features.
I don't think the author understands the nature of the "browser wars". He seems to think that none of the players have had the specific desire to have their browser dominate so that it could control, through the power of de facto standardization, exactly how HTML & kin will behave. There's one notable player, namely the one he's beseeching, who has historically been aiming at exactly that. I'll grant that it's possible that they're in the process of having a change of heart: maybe in the future their desire for market share will be a mere matter of pointing user's searches to bing instead of google. But we're still waiting on delivery of a version of IE that proves this.
For all we know, they could be stalling to switch strategies at the last moment possible. But I think it's more likely that they will strategically leave something like Canvas out and continue the same old strategy, but on a slightly different front.
I don't think the author understands the nature of the "browser wars". He seems to think that none of the players have had the specific desire to have their browser dominate so that it could control, through the power of de facto standardization, exactly how HTML & kin will behave. There's one notable player, namely the one he's beseeching, who has historically been aiming at exactly that. I'll grant that it's possible that they're in the process of having a change of heart: maybe in the future their desire for market share will be a mere matter of pointing user's searches to bing instead of google. But we're still waiting on delivery of a version of IE that proves this.
For all we know, they could be stalling to switch strategies at the last moment possible. But I think it's more likely that they will strategically leave something like Canvas out and continue the same old strategy, but on a slightly different front.
No, one company controlling the rendering would be a bad thing.
What they need to do (IMHO) is to have W3C create a reference implementation of the spec (and tests) and release that open source with say a BSD like license. So the different engines can use that if they want. Also if the browser doesn't display it exactly like the reference implementation then it shouldn't be called a web browser.
What they need to do (IMHO) is to have W3C create a reference implementation of the spec (and tests) and release that open source with say a BSD like license. So the different engines can use that if they want. Also if the browser doesn't display it exactly like the reference implementation then it shouldn't be called a web browser.
Does the author like AJAX? Because it grew out of Microsoft's initially IE-only XMLHttpRequest functionality. A marketplace in which multiple browsers compete and the best platform-specific features rise up to enjoy broader cross-platform support is what's best for the web. Dear Microsoft, please ignore this misguided blogger.
If MS changed their browser so significantly, many websites would break. A doctor's office I support uses dozens of web sites for insurance, lab results, hospital admissions, etc... I would have installed Firefox or Chrome on all the PCs if the web site worked properly on those browsers. The ugly truth is that many government and corporate systems _only_ test their sites in IE. Its a shame, but thats the state of the industry. If MS changed to WebKit, many of their enterprise customers would feel pain.
I really don't mind developing for the latest and greatest versions of the popular browsers. I think there is a surprising amount of congruency among them. Where it gets difficult is developing for older versions of browsers.
This article should have made an argument about retiring old browsers faster and getting people to use the latest versions sooner.
Other than that, I can empathize with his position. Web development is hard. I guess that's why we get paid to do it.
This article should have made an argument about retiring old browsers faster and getting people to use the latest versions sooner.
Other than that, I can empathize with his position. Web development is hard. I guess that's why we get paid to do it.
I don't understand how people who favour browser diversity can be making websites unless they are masochists. MS can use WebKit and still innovate. It's not either-or.
If MS would just implement the <canvas> tag (and according to the standard) then I'd be a little less disgruntled.
I really don't care if they all use WebKit or they all adhered more closely to some standard. I want less work for me to create a website. I guess I could always use Flash. ;-)
If MS would just implement the <canvas> tag (and according to the standard) then I'd be a little less disgruntled.
I really don't care if they all use WebKit or they all adhered more closely to some standard. I want less work for me to create a website. I guess I could always use Flash. ;-)
"I’m insane because it just makes too much sense to me and when something makes sense it usually means large corporations won’t do it"
Of course not. If a corporate IT department wanted everyone to use a WebKit browser, then they'd already have done it.
Of course not. If a corporate IT department wanted everyone to use a WebKit browser, then they'd already have done it.
Didn't read it all, but I think creating an unambiguous specification is indeed very hard, if not impossible.
Never gonna happen. Too many enterprise apps depend on IEs render engine and ActiveX.
Please don't.
If Microsoft starts using WebKit, they'll find a way to fragment it and make their implementation of WebKit incompatible and unmergeable with the rest of the crowd.
No. Please, Microsoft, stay away from the projects I depend on.
If Microsoft starts using WebKit, they'll find a way to fragment it and make their implementation of WebKit incompatible and unmergeable with the rest of the crowd.
No. Please, Microsoft, stay away from the projects I depend on.
That wouldn't be so bad, forking is where innovation can happen. The really bad part is when it would have the "Webkit" label in the user agent string, claim complete compatibility, claim they are using the most popular rendering engine, but being broken or incompatible in some fundamental way.
That doesn't make much sense, if MS creates their messed up own fork of Webkit, how does that hurt you?
Your stuff will still break in IE.
Your stuff will still break in IE.
Fragmentation.
It would still be called WebKit, but it would be somewhat compatible with other implementations of WebKit.
Remember Microsoft's Java.
It would still be called WebKit, but it would be somewhat compatible with other implementations of WebKit.
Remember Microsoft's Java.
How would it be any worse than it is today?
http://www.quirksmode.org/webkit.html
http://www.quirksmode.org/webkit.html
They would find a way ;-)
WebKit variations happen mostly in mobile platforms. That would be expected as the system resources are so much scarcer than they are on desktop computers.
WebKit variations happen mostly in mobile platforms. That would be expected as the system resources are so much scarcer than they are on desktop computers.
The argument for one browser vendor switching from engine A to another engine B "just like that" is entirely invalid unless engine B is strictly better than engine A. And by the looks of it there are areas in which IE9 Trident is going to be better than WebKit (e.g. hardware acceleration), which means that the argument is invalid. The argument for Mozilla switching to WebKit similarly falls flat -- Gecko is better than WebKit in several areas -- it is the only engine capable of rendering Firefox's interface, for instance.
"IE9 Trident is going to be better than WebKit (e.g. hardware acceleration)"
You must be joking. It's great that they have finally decided to add SVG support, but bragging about SVG "hardware acceleration" when they won't even commit to supporting the canvas tag is unconscionable.
It's also this kind of thing that makes it clear that either the IE team has its priorities completely out of whack or that Microsoft is trying to throw a spoke in the wheel of progress on the web.
Edit: I don't know what you hope to gain by downvoting. It doesn't change the fact that IE is and, from all indications will continue to be, the odd browser out.
You must be joking. It's great that they have finally decided to add SVG support, but bragging about SVG "hardware acceleration" when they won't even commit to supporting the canvas tag is unconscionable.
It's also this kind of thing that makes it clear that either the IE team has its priorities completely out of whack or that Microsoft is trying to throw a spoke in the wheel of progress on the web.
Edit: I don't know what you hope to gain by downvoting. It doesn't change the fact that IE is and, from all indications will continue to be, the odd browser out.
Right, MS is actively trying to slow down progress. Republicans eat old people's medicine, democrats want to kill babies. Facebook wants to steal your soul, Google wants your first born child. Sure.
I said "either." It's completely plausible that their prioritization process is disfunctional.
What's your explanation for why IE is consistently out of sync with the rest of the browser landscape?
What's your explanation for why IE is consistently out of sync with the rest of the browser landscape?
You're not getting the point. It doesn't matter that you provided an alternative, it's that you suggested the idea at all. That sort of sectarian bile I'd expect to find at Slashdot, not here.
> You must be joking. It's great that they have finally decided to add SVG support, but bragging about SVG "hardware acceleration" when they won't even commit to supporting the canvas tag is unconscionable.
No, it's not just SVG that will be hardware accelerated. Everything will be rendered in the GPU.
> It's also this kind of thing that makes it clear that either the IE team has its priorities completely out of whack
On what basis do you make this judgement? Why is supporting canvas better than making everything hardware accelerated?
No, it's not just SVG that will be hardware accelerated. Everything will be rendered in the GPU.
> It's also this kind of thing that makes it clear that either the IE team has its priorities completely out of whack
On what basis do you make this judgement? Why is supporting canvas better than making everything hardware accelerated?
"On what basis do you make this judgement?"
Because for the vast majority of web development, having browsers with similar performance to other browsers while supporting the same standards is vastly more preferable than having one widely-used browser with better performance in some areas that continues to make cross-browser development difficult or impossible.
Because for the vast majority of web development, having browsers with similar performance to other browsers while supporting the same standards is vastly more preferable than having one widely-used browser with better performance in some areas that continues to make cross-browser development difficult or impossible.
I disagree. I think given the choice to do only one thing out of the two, browser vendors should focus on things that fundamentally improve users' experiences with what they already have than implement random specs. I think the lack of canvas is disappointing too, but I think if the IE folks had decided to implement Canvas but not use Direct2D I'd be much more disappointed.
(Of course, you could be awesome like Mozilla and do both, but that's a different matter.)
This difference of opinion is exactly why the argument is invalid unless engine A is strictly better than engine B. WebKit is not strictly better than IE9 Trident.
(Of course, you could be awesome like Mozilla and do both, but that's a different matter.)
This difference of opinion is exactly why the argument is invalid unless engine A is strictly better than engine B. WebKit is not strictly better than IE9 Trident.
WebKit sucks, when it comes to performance, compared to Chrome and Opera. I'm sure you'll always find compatibility 'issues' but Microsoft is also planning to pull out all the stops when it comes to HTML 5 application performance.
Chrome uses WebKit as its rendering engine…
http://en.wikipedia.org/wiki/Google_Chrome#Development
http://en.wikipedia.org/wiki/Google_Chrome#Development
I would much prefer that MS wise up about the special requirements of a browser engine and do as well as they can with their own. Opera is more than welcome to switch to Webkit though. :)