Web standards

I woke up, to the [rumours] that were later confirmed that Microsoft were dropping their rendering engine EdgeHTML in favour of using Chromium. And I feared that we were heading right back to the days where one browser had over 95% market share. Where one browser could quite literally dictate the direction of the web.

Many of the things I have talked about […] were implemented by the Microsoft team. No, not in a perfect finished way, but enough for us to be able to experiment. Enough for us to try them out. Grid Layout was first implemented by the Microsoft Team in IE10. No, it [wasn’t] perfect, essentially a prototype for what was to come, but it enabled people to experiment.

[…]

Fewer browsers mean fewer experiments. Mean fewer places where things can start to evolve.

[…]

And I am not having a dig at Google here, again, there are some great people doing great things there, and the company is being a company doing what companies do - growing, succeeding. This isn’t a fight between good and evil. It’s a fight against a monoculture turning the web platform into the product of a single company. Whoever that company might be this time.

Developers, designers, and strategists, here’s something you can do for the health of the web: 

Test all your sites in Firefox.

Yes, we should all design to web standards to the best of our ability. Yes, we should all test our work in *every* browser and device we can. Yes, yes, of course yes. 

But the health of Firefox is critical now that Chromium will be the web’s de facto rendering engine. 

Even if you love Chrome, adore Gmail, and live in Google Docs or Analytics, no single company, let alone a user-tracking advertising giant, should control the internet.

[…]

When one rendering engine rules them all, well, many of us remember when progress halted for close to ten years because developers only tested in IE6, and more than a few of us recall a similar period when Netscape was the only browser that mattered.

[…]

When one company decides which ideas are worth supporting and which aren’t, which access problems matter and which don’t, it stifles innovation, crushes competition, and opens the door to excluding people from digital experiences.

In May 2019 I attended a talk by Mike Taylor who works on webcompat at Mozilla. Mike told the sordid story of window.event, a non-standard IE invention that was replicated in Konqueror, which showed up in Webkit, which stuck around in Blink, and was now Mike’s problem in Firefox. It was a good story fraught with ups and downs and literal “Breaking the Web” level changes for a tiny feature rollout.

At the end of the talk Mike threw out a pretty prescient question (Edge had just released its Chromium beta) and I’ve been mulling over it ever since:

What is the value of browser diversity? If Firefox switched to Chromium tomorrow, what would we lose?

– Mike Taylor, a traitor (apparently)

Mike made it clear that the question was purely theoretical and no serious talk about this was happening at Mozilla at the time. Nonetheless, it was a challenging thought. Throwing away all sunk costs, what is the value of the colossal expense required to employ engineering teams to chase Chrome’s tail?

I’ve thought about these questions for over a year and narrowed my feelings of browser diversity down to two major value propositions:

1. Browser diversity keeps the Web deliberately slow
2. Browser diversity fosters consensus and cooperation over corporate rule

They are similar, but slightly different concepts for me.

Slow, like brisket.

I think the Web platform’s most frustrating aspect is also its greatest asset: it’s slow. It’s not just slow, it’s “it took 10 years to ship the <main> element which is just a spicy <div>” kind of slow. It’s glacial.

This can be agonizing while you wait for a much needed feature to roll out in all browsers, only to find out five years in the process one browser refuses the entire premise of the feature (RIP HTML Imports). The big tradeoff is that web platform features have to run the gauntlet and more thinking is applied over time: robustness, naming, internationalization, accessibility, security, etc. all have proper time for consideration and aren’t rushed through like it’s a product sprint.

[…]

Cooperation, not corporation.

Browser diversity means browser vendors are hindered from shipping features that only benefit themselves (e.g. ActiveX in IE, -webkit-box-reflect, etc). Good ideas have to be open and meet a pseudo-requirement of ubiquitous utility. To make good platform features requires consensus, not competition, and the web’s potential is born out of cooperation, not a single corporation.

It’s hard to quantify this, but if all aspects of the Web (development, browsing, searching, hosting) are ceded to a single corporation, all it takes is one heavy-handed manager or executive hellbent on hitting some OKRs to push their thumb on the scale of the Web. If the Web is governed by a single corporation, it will start looking like that corporation’s vision of the Web, ultimately limiting its own potential. Trading short term gain on new shiny features for long term vision.

Yet another great example of why browser diversity matters and why Chrome’s overwhelming presence in both mobile and desktop use is harmful to the open web: some developers mistake Chrome’s adoption of an API as a web standard, when both Mozilla and Apple have serious concerns about the security of said API:

In issue #509 of JavaScript Weekly, Chrome’s new File System Access API was mistakenly referred to as an “open standard.” The author probably assumed that a feature with a specification and an implementation in Chrome must therefore be a web standard, but that is not necessarily the case.

The API in question is currently hosted by the Web Incubator Community Group (WICG), a place where browser vendors can propose, discuss, and develop new web platform features, and receive feedback from the wider community.

[…]

Google has been developing the File System Access API for at least the past two years and decided to ship it in Chrome in October (last month). As part of this process, Google asked both Apple and Mozilla for their official positions on the API. So far, their responses have not been positive (Apple, Mozilla).

It seems that Google decided to ship the File System Access API in Chrome without endorsement from Apple or Mozilla because it believes that this feature “moves the web platform forward”:

Interoperability risk is the risk that browsers will not eventually converge on an interoperable implementation of the proposed feature. … If a change has high interop/compat risk but is expected to significantly move the web forward, Chromium will sometimes welcome it.

Standardization and support from Apple or Mozilla is not a requirement for shipping a web platform feature in Chrome. However, because of Chrome’s large market share, there is a risk of such a feature becoming a de facto standard:

Changes to Chrome’s functionality create de facto standards. Market participants must adhere to these standards or risk their technology no longer being compatible with most websites.

Apple has a history of stunting the web’s progress on its platforms. On iOS, Apple doesn’t allow fully independent third-party browsers, requiring all apps to leverage its Safari browser when rendering web-based content. While browsers like Chrome and Opera are available in the App Store, they must use Apple’s Safari browser behind the scenes to render web pages, rather than their own. That means Apple has a monopoly on how iPhone and iPad users access the web. To push developers toward building native apps on iOS rather than using web technologies, Apple ignores popular parts of the open web specification that other browsers implement, to its own benefit.

A technology called WebRTC, for example, allows video calling in a web browser without additional software. It powers tools like Google Meet. But Apple was incredibly slow to implement the specification, leaving out key pieces of functionality, and the technology didn’t work when embedded inside apps.

Apple also handicapped an emerging standard called Progressive Web Apps (PWAs) — which, like Electron, allows developers to build native-like apps for both desktop and mobile — by partially implementing it in a way that makes it too inconsistent to rely on. PWA doesn’t have the same problem if users open apps in Chrome or Firefox, but iPhone and iPad users can’t install third-party browsers, which makes PWA-based technology a non-starter.

[…]

Apple’s subtle, anti-competitive practices don’t look terrible in isolation, but together they form a clear strategy: Make it so painful to build with web-based technology on Apple platforms that developers won’t bother. Now that the App Store is not accepting apps built using Electron, developers will likely find creative ways to work around it, but Apple is setting up for a continual cat-and-mouse game as it plans to exert more control over which apps can run on the platform in the future.

Given the recent demise of Presto and EdgeHTML rendering engines, and dominant market share growth for Chrome (and its Chromium engine), can we make a case for browser engine diversity in a decreasingly diverse browser engine world? In this talk, we’ll talk about web compatibility, interoperability, the web standards process, and hopefully conclude that we should care about these things in 2019.

One of the reasons I care so much about the web platform remaining open and accessible to new people who want to publish on and build things for the web is because of the route I took to get here.

As mentioned earlier, the W3C is celebrating their anniversary by inviting people to share stories of how they became involved in the web. In that spirit (and perhaps to encourage Smashing readers to share their stories), here is mine.

I had never intended to work with computers. I intended to become a dancer and singer, and I left school at 16 to go to dance college. My father is a programmer, however, so we were fairly unusual at the time as we had a computer in the house by 1985 when I was 10.

As a child, I liked typing in the code of “choose your own adventure” games, which appeared in books and magazines. I liked spotting the strings of text which would then show up in the game I would later play (usually, once my dad had fixed it up) on our Amstrad CPC464. I liked to visit the computer lab at Newcastle University, see the huge computers, and talk to the women who worked on them. Perhaps most importantly (and despite my arty interests), I never grew up thinking I couldn’t use computers. I just wasn’t especially interested.

[…]

Then I became pregnant with my daughter and had to leave the theatre. I was good at crewing and loved the theatre, but it was heavy and sometimes dangerous work with unsociable hours — not really a job for someone with a baby. I didn’t know what I would do, but I could type so I thought that perhaps I could type up essays for people. I was upsold to a computer — having gone into PC World looking for a wordprocessor. It was a Packard Bell 486 with a built-in 640×480 screen — a terrible machine that would allow me to either get the sound card working or the modem, but not both at once. I chose the modem and this is where my web story really begins. Even getting this modem working and getting the computer onto the Internet was something of a challenge and, once I did, I went looking for information about… babies.

I didn’t know anything about babies. All my friends were men who worked backstage in theatre. I had no support network, no family around me to help, and so I logged onto ParentsPlace and found people who didn’t mind my questions and were happy to help. At the time, there obviously was no Facebook. This meant that if you wanted to share photos and stories, you built a website. So among the forums about childbirth and toddler tantrums, there were people teaching each other HTML and sharing sets of graphics along with the code to place them. It was like typing out those “choose your own adventure” books again. I was amazed that I didn’t need anyone to fix my code — it just worked!

[…]

Before long, people would pay me to build them a website, and I felt that I should repay at least in some way for all of the questions I had asked. So, I started to answer questions in the forums. That was how it seemed to work. People would learn and move one step up the ladder, the new people would come in with the same questions and the people a step ahead would answer — all the while asking their own questions of those further along. I loved this. I could never have afforded lessons, but I had time. I could help others, and in return, people helped me.

[…]

I became interested in web standards essentially because it made no sense to me that we would have to build the same website twice — in order that it would work in both browsers.

A great discussion thread at the Web Incubator Community Group on creating a standardized way requesting that the browser lazy load images.

See also: Preventing downloading images or objects until they are visible in the viewport - WHATWG

This is an interesting discussion on the possibility of standardizing a way to request that the browser not load or delay loading images or objects. The key point that developers from the BBC stress is that for a non-zero number of users, JavaScript fails to run yet is enabled, so having a way to ensure they can still view images is important. As excellent as they can be, relying on on JavaScript solutions and serving non-functional markup can lead to broken pages in those cases since we don’t truly control our webpages.

See also: A standard way to lazy load images - WICG

This is an excellent, excellent collection of best practices on how to make your JavaScript more fault-tolerant, by Mathias Schäfer. Several sections deserve their own snippets:

• The browser as a runtime environment
• Failing fast
• NaN is contagious
• Conditional statements and truthy values
• Duck typing
• Strict Mode
• Abstraction libraries
• Error logging