Diary of an Engine Diversity Absolutist
Browsers play a pivotal role in the web, but does the web need multiple browsers? I think most web professionals would say yes, but how about browser engines, the underlying software platforms that browsers are built on? Does the web need multiple engines? If so, why? To unpack this a bit, we need to talk about “open.” In the web standards world, we like to make a big deal about how the web is open. But what does open mean? The web is open in the sense that anyone can build something with it – that there are no gatekeepers. It is also open in the sense that it’s built on top of open standards.
There are many definitions out there of what makes a standard open. One I particularly like is the UK Government Open Standards Principles which partially defines an open standard as one that has:
• collaboration between all interested parties, not just individual suppliers
• a transparent and published decision-making process that is reviewed by subject matter experts
• a transparent and published feedback and ratification process to ensure quality
You could say the web is “open” because the process by which it is developed and maintained adheres to these simple ideas of transparency, collaboration, and wide review between many stakeholders. It’s also open in the sense that you as a web user can choose what browser you use, and you can make that choice based on criteria that matter to you.
Today, in one of those Twitter arguments that I usually try not to get involved in, I saw the following statement from Alex Russell, head of standardization for Google Chrome (and a friend).
I have an enormous amount of respect for Alex and for the work he has put in to the web “project,” and he is not entirely wrong. His work on initiating the idea and some of the core components of progressive web apps alone make him one of the key contributors to the web platform.
However, Alex has gone on record here, and I think the wording he’s using, and its implications, need to be addressed. The sentiment about “engine diversity” points to a growing mindset among (primarily) Google employees that are involved with the Chromium project that puts an emphasis on getting new features into Chromium as a much higher priority than working with other implementations. As a web technologist, a member of the web standards community, and as someone who works on browsers, I think this mindset shift is problematic. So I would like to address that growing mindset and why I think it’s not a good thing for the web.
Ok – so let’s talk about concrete benefits of having multiple web rendering engines. Those of us who lived through the early 2000s will remember well the time period when Microsoft’s Internet Explorer had a strangle-hold on the Web. It may be difficult to visualize, but as recently 2008, IE had something like a 70% market share. In 2004, over 90% of web usage happened through IE. People who lived through that period of time remember what happened. Innovation on the web effectively halted – the web was considered by many to be a dead platform. It was the advent of a new browser, Firefox, powered by a new engine that revitalized the market and paved the way for the era we are living through today, an era of unprecedented innovation and growth of the web platform.
“But it’s not 2004, Dan,” I hear you saying. “And Microsoft’s Internet Explorer was closed source and proprietary, so this is a flawed analogy.” I hear you. Yes, it’s true, the Chromium platform is open source and has many other contributors besides Google, including my employer, Samsung (and Microsoft, for that matter). Actually, I am very much a supporter of the Chromium project, which I think is great and which has spawned many other browser projects that are moving the web forward in important ways.
There is still a matter of the governance for the Chromium project, which is very tightly bound to Google Chrome and to Google-employed people. Sometimes when I’ve been reviewing new web features that have been proposed by the Chromium team, I’ve been referred to documents written in Google docs, made available only to Google employees. Innovation of the Chromium platform is controlled by Google and bound to a Google vision of what the web is, and what the web should be, prioritized by Google based on their own strategic interests.
We also know from the MDN Web Developer Needs Assessment results from 2019 that cross-browser compatibility is one of the key pain points of web developers. Web developers care about compatibility between browsers and engines because their users are using those browsers and engines. This puts additional pressure on implementers to get wide review and develop their new technologies in an open and transparent manner.
As noted above, one of the key features of the open standards processes that underlie the web is wide review. The reason for wide review is to keep the web honest. The web is not just a single open source project. It is a medium which is part of the commons in a number of important ways. Wide review sometimes means people disagree with you. I’ve been honored to be a part of that wide review process through the reviews of new specifications that we’ve been doing in the W3C TAG, a process that was prompted in part by Alex Russell during his tenure on the TAG.
Since we started the formal process of TAG review in 2013, I’ve seen many many examples of new web features that have benefited from this process and approach. Because TAG review also includes a requirement to respond to our security & privacy self-review document, this also makes implementers think about and pay attention to security & privacy issues. You only need to look back at our 350+ closed issues to get a feeling for the impact that this process has had. But let’s take a look at a few recent examples to highlight where wide review has had a positive benefit. A few notable recent reviews where I feel we are making an impact (“when web standards go right”) are:
- Contact API I love this API because I have personally worked on maybe 4 or 5 projects that have sought to bring access to the someone’s address book to the web. And it’s something we do need if we want to create better user experiences for the mobile web, specifically for Progressive Web App developers. And it’s fraught with privacy issues because it’s an API that connects the wild web, a places that is riddled with malware and bad actors, to some of a person’s most valuable and most private information.
- The WebXR API: This is a great example of the web standards process working extremely well. The original API was developed in a W3C Community Group. When it became more mature, a W3C Working Group was created. This group brought in multiple browser implementers (including multiple engines), and other parts of the ecosystem. There was wide review, including a TAG review. Feedback from the wide review was taken on board and now implementations are being worked on and rolled out. We need more things like this.
- Clipboard Access APIs: This is another one of those powerful APIs that also bring risks to the web platform. This API is a really good example of an effort where wide review has made a difference. The original specification included some user flows that could have not had a strict requirement for user activation. Put another way, it could have meant that in some cases a web page that you happen to have open in a TAB could have had access to the contents of your system clipboard without your knowledge. Since the system clipboard often contains private information, we pushed back on this from the TAG and it looks like a re-think on these aspects is in progress.
- Badging API: This is another API that is really important for Progressive Web App developers, or anyone who wants build an application that has some control over the indication of “new activity that might require […] attention.” The original design was very Chrome-centric and very centered around PWAs. On the back of conversations between browser makers that happened at last year’s W3C TPAC meeting it looks like we are headed towards a design and approach that takes into account multiple approaches (for example, also including an indication in a browser tab on desktop as well as an icon on a mobile device).
Last year, I worked on a TAG finding, the Ethical Web Principles, which (among other things) reiterates the web is multi-browser:
“The constant competition and variety of choices for our users that come from having multiple interoperable implementations means the web ecosystem is constantly improving.”
Wide review for accessibility features has also historically been part of the story of the web. Without a culture of and mechanism for wide review, would we have had such a strong emphasis on accessibility?
In all of these cases, the back pressure that gives wide review any force, beyond a moral high ground, is the fact of multiple implementations. To put it another way, why would implementers listen to wide review if not for the implied threat that a particular feature will not be implemented by other engines?
So yes, I absolutely think multiple implementations are a good thing for the web. Without multiple implementations, I absolutely think that none of this positive stuff would have happened. I think we’d have a much more boring and less diverse and vibrant web platform. Proponents of a “move fast and break things” approach to the web tend to defend their approach as defending the web from the dominance of native applications. I absolutely think that situation would be worse right now if it weren’t for the pressure for wide review that multiple implementations has put on the web.
The web’s key differentiator is that it is a part of the commons and that it is multi-stakeholder in nature. In a world where one engine is beginning to play a dominant role there is a risk of reducing that set of stakeholders. We need stronger mechanisms to ensure more voices, and especially more diverse voices representing more of those stakeholders, to be part of the process of improving and evolving the web, not fewer. Those voices and stakeholders also need to be part of the conversation that shapes the future vision for what the web is. Multiple implementations are one way to help to ensure those voices will continue to be heard.
Thanks to Ada Rose Cannon and Andrew Betts for providing some feedback on this post.
Liked this post? Follow this blog to get more.