Chrome: Blink and You Missed the News

It's old news by this Thursday morning, but in case you had not heard, Google is forking WebKit to make its own rendering engine, Blink. Opera will be using the Blink fork of WebKit as its rendering engine.

A combination of people who are far smarter, far more well connected, and in timezones that allow them to write about this sooner, along with all the Twitter chatter, has already hashed out the major details. As such, I will link to them below. I would be a terrible blogger if I didn't offer my opinion, however.

I will format this the way I did when I provided my in-depth analysis of Opera's move to WebKit (away from Presto) less than two months ago.

So what does this really mean?

For Developers

Any developer who is complaining that this means there is another browser/engine against which they will need to test has been doing it wrong.

Web developers should always test against different browsers, regardless of their engine. In particular, WebKit has so many nuanced implementations that not independently testing against each browser that uses WebKit belies either a lack of understanding of how WebKit is implemented or laziness.

If you aren't sure what is different between each WebKit implementation (Chrome, Safari, Android browser, Opera, etc.), I encourage you to read my post "WebKit Will and Won't Be the New IE," where I provide a high-level overview of these variances.

For Users

At this point it doesn't mean a whole lot.

Google will argue this is better for users. Apple will argue that Google took its ball and left. Opera won't be arguing. None of that impacts users because we have mostly done a good job of promoting standards-based development. I again refer you to "WebKit Will and Won't Be the New IE" for how poor testing can impact users, but that's not a function of the engines.

Because Apple only allows WebKit on iOS devices, and even then it restricts those browsers to a different JavaScript engine and thus a lesser experience, Chrome and Opera for iOS may still stay on WebKit. Over time as its harder to incorporate features from Blink back into the WebKit core, there may be feature divergence which may affect users.

That's just speculation on my part.

For Standards

For a specification to become a W3C recommendation, there must be two 100% complete and fully interoperable implementations, which basically means two browsers need to support it. When Opera announced the shuttering of Presto, that left Trident (Internet Explorer), Gecko (Mozilla), and WebKit (Safari and Chrome) as the remaining engines (of measurable size). Essentially, two out of the three of them had to agree to implement a feature.

With Blink, provided the W3C recognizes it as a stand-alone engine, there is now one more engine back in the mix, essentially returning the count to where it was in February before Presto's wind-down (to be fair to Presto, it's expected to exist in the wild until 2020, but with no new feature development).

I am hoping that this is a good thing for standards.

Blink won't be using vendor prefixes (even though it will have inherited some), so I consider that a step in the right direction. While I think this matters to developers, I think it matters even more to standards.

Technical Aside

From Peter-Paul Koch:

Chrome 28 will be the first stable release to use Blink; earlier versions will use WebKit. Opera and Yandex will start using Blink whenever they start using Chromium 28.

Related

First some bits from The Twitters:

Let's bring back the Netscape engine and call it Spacer! RT @codepo8: After blink Microsoft might bring out a new engine called marquee

— Adrian Roselli (@aardrian) April 4, 2013

And *this* is how you fork a repo.

— Sylvain Galineau (@sgalineau) April 3, 2013

Can the new Blink logo be >_<?

— Mike Taylor (@miketaylr) April 3, 2013

And now to the related links:

• Blink: A rendering engine for the Chromium project, April 3, 2013.


• Developer FAQ, The Chromium Projects.


• Hello Blink, from Bruce Lawson (who clearly hates Morrissey doesn't care for most of Morrissey's solo work).


• Hello, Blink! from Paul Lewis


• Discussion on Hacker News about how Google controls WebKit.


• Well, err, that solves the WebKit monoculture problem, from Jake Archibald.


• Google Announces Blink, Its Own Rendering Engine For WebKit. at Read Write


• Blink from Robert O'Callahan.


• Discussion on Hacker News started from Apple's perspective.


• Google going its own way, forking WebKit rendering engine at ars technica.


• Just One WebKit from James Socol.


• Why What You’re Reading About Blink Is Probably Wrong from Alex Russel.


• Blink. Chrome’s new rendering engine from Eric Bidelman.


• [webkit-dev] Cleaning House thread at the WebKit mailing list in the wake of the Blink news, along with the announcement on the list.


• A Short Translation from Bullshit to English of Selected Portions of the Google Chrome Blink Developer FAQ from Rob Isaac.


• Blink from Peter-Paul Koch.


• Another first by Opera! from WebKit Memes.


• Thoughts on Blink from Krzysztof Kowalczyk.


• Welcoming Blink, Chromium’s new open source rendering engine from Peter Beverloo.

There's this one from 2010 by Haavard Moen that I thought worth highlighting: "Dear Google: Please fork WebKit."

Update, 5:35pm

A video Q&A from Google Developers about Blink (time markers available on the Chromium blog).

Read More

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.

Read More

Opera: Presto! It's now WebKit

Opera is replacing its Presto rendering engine with WebKit (Chromium, really, when you factor in the V8 JavaScript rendering engine). Big news as of this morning.

If you've been paying attention, it's not really that big or news. About a month ago a video was leaked showing Opera using WebKit (the video has since been pulled from YouTube). Within the last three weeks two of the Opera folks I follow on Twitter are suddenly no longer Opera folks (Tiffany Brown, Patrick Lauke). Heck, even Opera's founder sold off some shares yesterday. If you paid attention, you knew something was up.

All of that aside, what does this really mean?

For Developers

I feel most web developers already ignored Opera. For those developers they can continue to be lazy and ignore Opera.

For Users

The short term impact on users will be minimal. Users will upgrade, users will surf, users may notice some sites work or look a little better.

For users trapped on old Android devices with the Android stock browser (that never seems to upgrade), this could result in a better experience — assuming these users know about and download the Chromium-powered Opera.

For Standards

Opera has an impressive place in the mobile world, being at the top of the pile globally. Opera's participation in the standards process has been valuable, partly because its rendering engine has been used to help move the process forward thanks to early implementations, differences in implementations, and arguments over implementations.

While the standards evangelists at Opera may do a great job of contributing back to Chromium, Google may be the block from those changes being committed. Even when changes get to Chromium, there is no guarantee that they'll make it back into WebKit, which might involve getting past Apple. Only if those changes get into WebKit do they stand a chance of making it Apple's Safari.

From the co-chairman of the W3C CSS Working Group, Daniel Glazman:

For the CSS Working Group, that's an earthquake. One less testing environment, one less opportunity to discover bugs and issues. Let me summarize the new situation of the main contributors to the CSS Working Group:

• Microsoft: Trident


• Apple: WebKit


• Google: WebKit


• Opera: WebKit


• Adobe: WebKit and their own Adobe Digital Editions rendering engine found in many ebook readers


• Mozilla: Gecko


• Disruptive Innovations: Gecko


• HP: has delivered WebKit-based products in the past but is pretty browser-agnostic IMO


• Rakuten: ADE and probably WebKit


• Kozea: WeasyPrint


• Qihoo 360 Technology Co: both Trident and WebKit


• other Members of the Group: I don't know

Suddenly I feel like the US political term lead from behind is apt.

Some other reactions from the Twitters:

It’s becoming clear that WebKit:browsers::MS Word:word processors.

— Eric A. Meyer (@meyerweb) February 13, 2013

And all other engines perished to make way for the best, most popular one.It was called IE6 and the year was 2000…Remind you of something?

— Lea Verou (@LeaVerou) February 13, 2013

Related

...to the news about Presto

• Opera Ice: New browser for Android and iPhone coming February uses WebKit (video), January 18, 2013 from Pocket-lint.


• WebKit is not a cure-all, February 1, 2013 from Tiffany Brown, formerly with developer relations at Opera.


• 300 million users and move to WebKit, February 13, 2013 from Opera itself.


• And Then There Were Three, February 13, 2013 from Robert O'Callahan.


• Strange day for the Open Web, February 13, 2012 from Daniel Glazou.


• Jake Archibald gives his take over at Google+, February 13, 2013.


• Opera switching to WebKit: thoughts and guesses, February 13, 2013 from Peter-Paul Koch.


• The WebKit Culture & Web Rendering Engine Diversity, February 13, 2013 from Robert Nyman.


• I will miss the “Douglas Crockford of browsers” February 13, 2013 from Christian Heilmann.


• One less browser engine, February 13, 2012 from Tristan Nitot.


• Opera and WebKit: a personal perspective, February 13, 2013 from Bruce Lawson (from Opera, the guy who wrote the announcement I link to at the start).


• Hey Presto, Opera switches to WebKit, February 13, 2012 from Ars Technica.


• Devs respond to Opera WebKit switch, February 13, 2013 from .net Magazine.


• Presto Change-o, February 13, 2013 from Eric Meyer.


• Bruce Lawson on Opera’s Move to WebKit, February 13, 2013 from A List Apart.


• Hey -o-, let’s go!, February 13,2013 from David Storey.


• Another chapter of a long goodbye? February 14, 2013 from Charles McCathie Nevile.


• WebKit: An Objective View, February 14, 2013 from Robert Nyman and Rob Hawkes.


• A few folks have asked me what I think of the news..., February 15, 2013 from John Lilly.

...to older bits

• Browser Makers Caving to Vendor Prefix Misuse on this blog, Feb. 9, 2012.


• CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*, February 9, 2012 from Daniel Glazou.


• Reading List – Vendor prefixes, mobile, monoculture by Bruce Lawson, Feb. 13, 2012.


• The iPhone monoculture by Peter-Paul Koch, Feb. 20, 2012.


• Developers focus on the iPhone too much at .net Magazine, Feb. 21, 2012.


• Report on the activity of companies in the WebKit project, February 6, 2013.


• Don't Blame Opera, Blame Devs on this blog, April 27, 2012.

...And evidence that lazy developers can keep on keeping-on (from almost a year ago):

I don't include the -o- prefix because I don't test in Opera because it accounts for 0.3% of our visitors. Not because I'm lazy or inept.

— Stephanie Hobson (@stephaniehobson) April 26, 2012

Update, February 14, 2013

Since I posted this, some folks have asked just what Opera did that was so useful? This quote from David Storey's post outlines some of it pretty well:

Moving from HTML to CSS based layouts? Opera was perhaps the first to have a useable CSS engine. Håkon (father of CSS, and Opera CTO) often says it was the reason he started to believe a browser could be made in Norway, not just the USA, and joined Opera. AJAX? Opera reverse engineered this from MS’ ActiveX based approach and were the spec editors through Anne van Kesteren. HTML5? Started at Opera with Ian Hickson and others. Responsive web design? Media Queries came from Opera, and were implemented for years before showing up in other browsers. What about native video on the Web? Opera again.

Read More