Dear Microsoft, please use WebKit
drawar.com
drawar.com
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. :)
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 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.
Things like this will serve the web better than "Hey everyone, let's all use Webkit".
http://www.quirksmode.org/webkit.html
So, even if MS did convert to webkit, which webkit?
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.
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.
It will be interesting to see when this happens again.
Hasn't occurred to him that maybe MS also has invested too much in its rendering engine?
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.
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 )
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.
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.
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.
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.
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.
#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>
Can you give some example code of your problem? Also why would you ever be combining float and position:fixed? To my knowledge, if you set position to absolute or fixed, float is automatically be computed as none.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.
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.
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.
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.
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.
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. ;-)
Of course not. If a corporate IT department wanted everyone to use a WebKit browser, then they'd already have done it.
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.
Your stuff will still break in IE.
It would still be called WebKit, but it would be somewhat compatible with other implementations of WebKit.
Remember Microsoft's Java.
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.
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.
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?
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.
(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.
What's your explanation for why IE is consistently out of sync with the rest of the browser landscape?