Article
One Dream, One Web Browser Rendering Engine
Note: The title was inspired by Eric’s China trip a few months ago. Yes, that’s how long I’ve been sitting on this post.
During one of our IE bitchfests (a sad reality of doing front-end work on the web), Matt and I got to talking about why every web browser needs a different rendering engine in 2006 and beyond.
Can you think of a good reason?
We couldn’t either.
Matt put it most eloquently, in an email he passed around the office:
In a perfect, never-will-happen world, we’d have one global standard rendering engine and platform makers would add all their value through integration above the back/next button layer — RSS, desktop search, interpersonal communication, the works. I just don’t see how [anyone] gets any competitive advantage from the rendering engine anymore. It should be everything from that point and above in the stack that makes their case.
Given the amount of time developers spend on cross-browser troubleshooting, and the number of times you’ve seen “sorry, this browser is not supported” while trying to visit a site, I think this scenario makes a lot of sense.
Of course, there’s history to this story. A lot.
Adding new features to the rendering engine (<blink> tag, anyone?) used to be one way browser makers could distinguish themselves. But now, web standards rule, and web developers and browser makers realize the benefits of making the web as accessible as possible.
Today, all of the browser innovation is happening above the rendering level. Firefox, Safari, Opera, OmniWeb and others are not loved because they render pages well (while it’s nice, it’s just par for the course) — it’s the cool features that turn experiments into favorites.
But then again, this is all just a pipe dream. Probably. Yes, it is.