Showing posts with label WebKit. Show all posts
Showing posts with label WebKit. Show all posts

Tuesday, February 3, 2015

Best Viewed in 1 of 11 Flavors of Chrome!

Make sure you view this on Google's flavor of Chrome, otherwise, well, I have no idea what will happen.

Sometimes it's frustrating being a developer who's been around to see Mosaic supplanted by Netscape Navigator supplanted by Internet Explorer supplanted by Chrome/WebKit. Developers just love dumping one platform for the new shiny.

As I said last week, all of this has happened before and will happen again. The difference with this post is that I am not going to rant about lazy developers whining over a world that will still contain Internet Explorer and its offspring.

Instead, let's ask the average anti-IE / pro-WebKit developer a very simple question — on how many flavors of Chrome do you test?

I don't mean how many versions of Chrome. I also don't mean how many different WebKit-based browsers. No, how many flavors of Chrome?

I'll guess probably not more than a couple. I have four that I can, but typically don't, use. Even at four that's far too few.

Today Peter-Paul Koch pointed out that there are eleven (11!) flavors of Chrome (Chromia, if you will). All of them built on Chromium. Here's the breakdown from his article:

Vendor Version Tested Default Remarks
Google 40 Yes Yes
Opera 39 Yes No
Yandex 38 Yes No
Xiaomi 34 or 35 Yes Yes Zoom reflow
HTC 33 Yes Yes Zoom reflow
Cyanogen 33 Yes Yes
LG 30 Yes Yes Mid-range
Puffin 30 Yes No Proxy
Samsung 28 Yes Yes
Amazon 37 No Yes Silk
LG 34 No Yes High-end

You may have noticed that this only accounts for mobile devices. Some on Twitter also noted Chrome on Google TV, or on Android TV, which doesn't account for the Samsung Android TV nor the Sony Android TV.

So maybe it's fifteen (15!) flavors of Chrome. Either way, I suspect that number will continue to grow.

Even if I include IE6, I only have to worry about 5 versions of Internet Explorer across mobile and desktop. If I want the idyllic WebKit-only world so many seem to crave, then I need about a dozen flavors of Chrome before I can get started with the Operas, Safaris, Yandexes, and Vivaldis (plural because those forks of WebKit also have their own versions to support)

All of this written against the backdrop of a Medium post claiming it won't consider IE11 a Tier 1 browser because of what it considers an ugly border in the editor view. Unable to find IE developers anywhere, nor to figure out where to file a bug, Medium just browser-sniffs IE11 into a second tier. I'm sure Medium tested across eleven flavors of Chrome, though.

Please read PPK's piece: Chrome continues to fall apart at brisk pace

Thursday, April 4, 2013

Chrome: Blink and You Missed the News

The new Blink logo. 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:

And now to the related links:

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).

Tuesday, March 12, 2013

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

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

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.

Wednesday, February 13, 2013

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:

Related

...to the news about Presto

...to older bits

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

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.