Is Blink the new IE6?

The Big Question

We all loved IE6 which gave us web monoculture. Are we repeating the same mistakes again with Blink?

Google

don't be a sock-puppet! We do a ton of stupid stuff all the time and need constructive criticism for Blink to be more awesome for everyone involved. Bring it on!

An open letter from WaSP

TWO YEARS AGO, when your market share was still high as a kite, you pledged to fully support five key standards in the next version of your browser…

At last you are talking about shipping product by the end of the year. Sounds great – except that it’s the wrong year.

Continuing to periodically “upgrade” your old browser while failing to address its basic flaws has made it appear that you still consider Navigator 4 viable. It is not.

…keeping your 4.0 browser on the market has forced developers to continue writing bad code in order to support it.

If you fail now, the web will essentially belong to a single company. And for once, nobody will be able to blame them for “competing unfairly.”

So please, for your own good, and the good of the web, deliver on your promises while Netscape 6 still has the chance to make a difference.

The critics loved it!

Internet Explorer 6 beta shows great promise

Microsoft Internet Explorer offers few quirks and many superb features... After introducing IE-only layout features such as scrolling marquees and colored table borders in earlier versions, Microsoft is now committed to the standards set by the World Wide Web Consortium.

WaSP loved it!

IE6 for Windows delivers fine support for HTML 4, CSS-1, and other important W3C standards.

Everybody loved it!

I Love This Browser! I have loved browsing the web since I started way back in the mid 90s, and I really love browsing with IE.

We loved

• DOCTYPE switching (for broken box model)
• ActiveX
• HTML Components (.htc files)
• CSS Expressions
• Coloured scroll bars
• IE filters and DHTML behaviors

Vendor Prefix spec

Keywords and property names beginning with -' or '_' are reserved for vendor-specific extensions. For example, if XYZ organization added a property to describe the color of the border on the East side of the display, they might call it -xyz-border-east-color.

VWe all read specs, right?

Authors should avoid vendor-specific extensions.

WebKit's rationale

hober: if it's used on the web, it's hard to argue that we should remove it and make those pages render worse.

I'm an English literature graduate

Vendor prefixes are like skidmarks on the underwear of web standards: sometimes unavoidable, but best washed and rinsed out as soon as possible.

We're all acutely aware of what happened with IE and don't want to see that happen again. All the work on de-prefixing for example came out discussions on that issue and the feedback from Opera in particular.

Vendor Prefixes can be harmful to compatibility because web content comes to rely upon these vendor-prefixed names. Going forward, instead of enabling a feature by default with a vendor prefix, we will instead keep the (unprefixed) feature behind the “enable experimental web platform features” flag in about:flags until the feature is ready to be enabled by default.

Removed by @foolip

• HTMLMediaElement.webkitPreservesPitch
• HTMLMediaElement.webkitHasClosedCaptions/ webkitClosedCaptionsVisible
• Performance.webkit*
• -webkit-transition media feature
• Performance.webkitGet*

For legacy vendor-prefixed features, we will continue to use the -webkit- prefix because renaming all these prefixes to something else would cause developers unnecessary pain. We've started looking into real world usage of HTML5 and CSS3 features and hope to use data like this to better inform how we can responsibly deprecate prefixed properties and APIs.

The Mobile Web should just work for everyone

In Windows Phone 8.1 Update, we added a mapping of popular webkit-prefixed APIs to the standards based support already part of IE11.

Google's Director of Web Platform

I was the Engineering Manager for Client Platforms at Microsoft in the early 2000s and in large part responsible for most of the engineering resource being pulled from IE\Trident. Oops :/

The issue for Microsoft back then was that a successful web actually went against their business goals, to the tune of many $B. That's definitely not the case for Google, indeed it's the opposite, as a company we benefit when more people use the web so there's absolutely no conflict of interest.

it's clear Microsoft is now on a very different path than when I was there and investing heavily in web stuff. Indeed they've become more open in the last 6 months than they've been in more than a decade which is great to see!

we [Google] know that the reason the web as a platform is successful (vs native alternatives) is *because* there is no one company in charge, it's a defining characteristic and something we're unequivocally committed to.

Google: conflict of interest?

The Google Play Store mobile app revenue will catch up to Apple’s App Store in 2018

Projected $9bn/ pa (2013: total Google revenue $55.5bn)

Ian again:

Play revenue has never come up with us and the guidance we've always gotten from Larry, from Sundar and every senior exec here is to just go make the web better. Perhaps it's because we make so much more money off search and ads? Dunno.

Opera's perspective

We have an App business but ultimately we want the web to win.

We're the only browser maker that isn't trying to sell you a mobile OS or a locked-down device.

Blink's 2014 goals

Web usage continues to shift from desktop to mobile. Yet the mobile web remains far from reaching its potential -- in part because web engines (e.g. Blink) are not nearly as good on performance-constrained devices as they need to be. To be successful on mobile, Blink must exit 2014 much more mobile-awesome.

The webkit vs Blink analysis

the Blink project has been more focused on next-gen webapps with a heavy focus on the compositor, scheduling, and style subsystems. The WebKit project has been more focused on documents and improving existing pages with faster line layout and style selection

CSS Regions

I have come to understand that Regions both does not play well with existing performance optimizations [and] impedes ongoing simplification and optimization work to our core rendering code

Opera

CSS Regions Considered Harmful - Håkon Wium Lie

From Opera's side we agree with the prioritization of performance optimizations in Blink, and we'd be happy to help identify issues and improve that aspect of the Regions code.

It's fair to say we kinda screwed up with the Regions work with Adobe. We do want Blink to be 'true' open source and indeed take major contributions from outside Google. The issue with Regions was that we were supportive of the feature in principle but once the patches started to land we realized how much it was going to conflict with other work going on in Blink. We had to mediate and unfortunately picked the mobile apps performance work over Regions.

… Hopefully Regions will land still but perhaps with a different, more complementary, implementation. Anyway, we learned an important lesson and since have tried to improve our processes to ensure that implementation conflicts don't happen with the whole "Intent to..." process… I think it's fair to say we're still learning here though and would encourage more feedback on how we can be more open.

My initial hopes for Blink

I also hope that it’s easier for smaller players and even individuals to contribute to the new rendering engine, with a more transparent gatekeeping process: “Our goal is for anyone to be able to participate, regardless of organizational affiliation.”

8 Dec 2011: my strawman

<picture alt="angry pirate">
<source src=hires.png media="min-width:800px">
<source src=midres.png media="network-speed:3g">
<source src=lores.png>
   <!-- fallback for browsers without support -->
   <img src=midres.png alt="angry pirate"> 
</picture>

<picture> element

the RICG’s main contribution to the web platform wasn’t picture, srcset, or sizes… To get them done we had to punch a hole through the thick technical, cultural, and institutional walls that separate the people who make browsers from the people who make websites.

Crowd FUNding

Bridging gaps is, of course, significantly easier when you’re able to crowdfund a Renaissance-man like Yoav [Weiss] who can contribute meaningfully at every level.

Is monopoly bad?

only 12.2% of the Fortune 500 companies in 1955 were still on the list … in 2014, and almost 88% of the companies from 1955 have either gone bankrupt, merged, or still exist but have fallen from the top Fortune 500 companies… Most of the companies on the list in 1955 are unrecognizable, forgotten companies today.

Is Google a monopoly?

Google is bent on establishing platform domination unlike anything we've ever seen, even from late-1990s Microsoft. Google controls Android, which is winning; Chrome, which is winning; and key Web properties in Search, Youtube, Gmail and Docs, which are all winning.

Is Blink a monopoly?

• IE6 had 90% market share, on desktop
• MS was generally hostile to the Web
• Blink is open-source; Trident isn't
• Browser vendors have urgent need to collaborate

The existential threat

For HTML5, it was Rich Internet Applications:

A lot of the work started because we were really scared of Silverlight.

It's an App World.
The Web Just Lives in It

Today, the U.S. consumer spends an average of 2 hours and 38 minutes per day on smartphones and tablets. 80% of that time (2 hours and 7 minutes) is spent inside apps and 20% (31 minutes) is spent on the mobile web.

Service Workers CheatSheet

• registered Service Workers are invoked even when offline, so enable apps that are "offline by default"
• normal resource loading is the fallback behavior
• it forces you to have URLs! Some modern apps platforms have foresaken this core principle of the web and suffer for it. The web should never make the same mistake.

navigator.registerServiceWorker
  ("/*", "/assets/v1/ctrl.js").then(
    function(serviceWorker) {
		  console.log("success!");
		  // call window.location.reload()
		},
	  function(why) {
	    console.error("failed!:", why);
    }
);

There's an app API for that

• File API
• Orientation
• Sensors (humidity, ambient light)
• WebRTC
• Drag'n'Drop

App store discoverability

Device APIs not so much anymore, now that many/most of what is needed is now there or soon to be. (Especially so with WebRTC.)

App Stores for discovery is big.

Monetizsation

I don't buy the monetization story, because if I did, that means I endorse $1 business models based on manufactured scarcity. ;P

…but for Web Payments see web-payments.org

Engagement

Push Notifications for the engagement part of the story.

Usability

• People prefer the familiar; Users trust known resources
• Mobile users bookmark differently. Bookmarks in mobile browsers are used sparingly, instead mobile users "bookmark" by downloading the native app.

User Experience Stack Exchange: Any Research on User Experience Perceptions of Native Apps vs Web or Hybrid Apps?

Scott Jenson

• integrate in the list of apps directly available to the user. This means that it should show up on that OS's home screen and be launched just like any other native app.
• integrate into the the OS task-switcher. If the user switches from a web app to a native app, such as the contacts manager, they shouldn't have to switch to the web browser and then switch to the web app.

Bookmarking = installing

<meta name="mobile-web-app-capable" content="yes"> (see Chrome docs)

<meta name="apple-mobile-web-app-capable" content="yes"> (Apple docs)

Web Manifest

• <link rel="manifest" href="install.json">
• the web application's name, links to icons
• the preferred URL to open on launch
• default orientation, fullscreen indicator

w3c.github.io/manifest/ - Mozilla's Marvellous Mr Marcos' magical manifest

Installability

• install itself from any web page
• user experience to install a web app should not be just saving a bookmark. Apps should be able to have an ‘install link' on any web page that starts the safe process of downloading the app package to the device.

W3C: Enabling new types of web user experiences

W3C Widgets

a packaging format and metadata for … full-fledged client-side applications that are authored using technologies such as HTML and then packaged for distribution. Examples range from simple clocks … to complex applications that pull data from multiple sources

Attwood's Law

Any application that can be written in JavaScript, will eventually be written in JavaScript.

Lawson's Law

Just because you can vomit a DOM out of JavaScript doesn't mean you have to.

Holy Grail App

we've launched our first Holy Grail app into production! … It looks exactly the same as the app it replaced, however initial pageload feels drastically quicker because we serve up real HTML instead of waiting for the client to download JavaScript before rendering.

Holy Grail App #2

Plus, it is fully crawlable by search engines. … It feels 5x faster.

What the web needs

• Browser vendors to work together for interop
• Standards that preserve core strengths of Web
• An end to silos
• Web developers to preserve core strengths of Web
• Test on all browswers

Thanks

• Ian Ellison-Taylor (Google)
• Lars Erik Bolstad (Opera)
• Philip Jägenstedt (Opera)
• Patrick Lauke (Paciello Group)
• Brian "Bobble Bon-Bon" Leroux (Adobe)

Image acknowledgments

• Me by HTML sign in Tokyo by Doug Schepers (@shepazu)
• Apps vs Web graphs by Flurry, used by permission
• Blink/ WebKit fork analysis graphs by Philip Rogers, used by permission.
• Pitcher by voteprime
• CSS Regions logo courtesy of Adobe
• Mind the Gap - Reinhard Dietrich

More acknowledgments

• Opera's Blink commits cake photographed by Andreas Bovens
• PhoneGap diagram: Adobe; Brian LeRoux pic courtesy of Brian
• Conversation photo by Chuck Patch
• Postbox and clown made by Murfalizer. Clown by Nat Ch Villa
• HTML/ CSS Presentation Framework: Shower by Vadim Makeev.