WebKit Will and Won’t Be the New IE

Web developers have been looking to call everything the new Internet Explorer for a while now. With Opera’s recent move to WebKit as its rendering engine (replacing Presto), even more developers are suggesting that WebKit is becoming the new IE.

I think they are right, but for the wrong reasons.

How WebKit Won’t Be the New IE

nice! opera for android beta includes support for @ supports. AFAIK, the first WebKit-based browser to release with it.

— Tiffany B. Brown (@webinista) March 6, 2013

Unlike Trident (Internet Explorer’s rendering engine), WebKit can be wielded in many different ways by many different browsers. It’s less a singular rendering engine and more a collection of pieces and parts that can be assembled in different ways. The tweet above demonstrates that there can be different WebKit implementations.

You may argue that the example above is just a case of the first implementation of an update that will make it into all browsers that use WebKit. That may very well be true (we don’t know yet), but there are many more examples of differences as Paul Irish painstakingly details in his post WebKit for Developers. I encourage you to read it because it’s an almost hilarious dive into the rabbit hole of WebKit. The most salient and clear point is the bullet list of what is not shared in WebKit ports:

• Anything on the GPU
  • 3D Transforms
  • WebGL
  • Video decoding
• 2D drawing to the screen
  • Antialiasing approaches
  • SVG & CSS gradient rendering
• Text rendering & hyphenation
• Network stack (SPDY, prerendering, WebSocket transport)
• A JavaScript engine
  • JavaScriptCore is in the WebKit repo. There are bindings in WebKit for both it and V8
• Rendering of form controls
• video & audio element behavior (and codec support)
• Image decoding
• Navigating back/forward
  • The navigation parts of pushState()
• SSL features like Strict Transport Security and Public Key Pins

That amounts to quite a lot of potential variance between WebKit-powered browsers, which is how WebKit is not the new IE.

How WebKit Will Be the New IE

IE10 has been out mere hours, and I already see devs bragging about dropping IE9 support. Do these people build for users or ego?

— Adrian Roselli (@aardrian) February 27, 2013

Far too many developers are always looking for ways to justify testing less. It could be laziness, it could be lack of access to enough device configurations, it could be … well, frankly, I think it’s the first one. My IE10 tweet above was based on watching people thrilled as much at taking a shot at Internet Explorer as they were at feeling they could test on one fewer browser.

Developers may use the common engine in one browser as justification for not testing on all the WebKit browsers, or they just may not know about the potential for dramatic differences between implementations. What happens when everyone builds for one awesome browser engine (or one perceived common engine)? We end up with a browser monoculture, devoid of testing for other variations.

As a web developer since the dawn of the web, I’ve seen it happen before. I remember surfing on Netscape only to find a site didn’t take into account my screen colors or resolution, or on Internet Explorer only to find a site didn’t take into account my laptop pixels-per-inch default. I was using the popular rendering engine of the day, but the assumption that all users on that engine would all have the same experience was wrong then, and it will be even more wrong now.

WebKit will become the new IE if web developers continue these false assumptions and fail to test other WebKit implementations. Developers will build for one implementation, test for it and maybe a couple variations, and call it a day.

Conclusion

My fear is that all the gains we’ve made in the last few years toward a more inter-operable standards-based web (leaving behind the Internet Explorer monoculture) will fall away as we unwittingly move toward a WebKit-tweaked yet non-multi-WebKit-inter-operable web.

In short, we’ll test for one WebKit, not realize (or care) about all the other variations, and end up breaking the web all over again.

WebKit won’t be the new IE, but WebKit will be the new IE.