How to build a web browser — Part 1: Specifications

Browsers are a complex piece of software: inside a web browser there are features comparable to a whole operating system. Every time I googled how to make a web browser, the answers were quite shallow, usually talking about how to consume some browser engine and make something on top of it. This article aims to walk through the whole process of making a web browser. On part 1, I’m going to talk about specifications.

In my lifetime experience as a developer, I learned that executing the code is usually the easiest part of the software development process. What really takes time and effort is defining how it should work. That’s what organizations such as the W3C and WHATWG do.

The W3C— World Wide Web Consortium — is an international standards organization, which maintains full-time staff for the purpose of working together on the development of standards for the web. Until 2004, the W3C was the main responsible for standardizing the web.

To this day, most new features required long periods of time for standardization, followed by implementation by many browser vendors, only then followed by developer feedback and iteration. But this workflow is changing…

In 2004 an organization formed by Mozilla, Apple, and Opera Software named WHATWG — Web Hypertext Application Technology Working Group — was born in response to the W3C wanting to pursue XHTML2 — which had no interest from browser vendors. Their proposal was to evolve HTML, rather than invest in XML based technologies, this evolution is known today as HTML5.

WHATWG proposes a different way of thinking specifications, they call it a living standard:

This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.

But not every feature comes from a standardization group. Sometimes, browser vendors implement a feature needed for its own business and never share a specification with the community. This practice is harmful to the health of the open web and forces browser vendors to spend energy on compatibility, rather than innovation.

If you read this link, you’ll see it is a specification document for window.orientation, a feature created by Apple that never really got specified anywhere, so Mike Taylor wrote a spec for it. Actually, if you take a good look at the previous link, you will see that the whole document is about documenting non-standard features so all browsers can be compatible.

But as I mentioned before, things are changing, the community is becoming more mature and the process is getting better. Today it is a lot easier to play a part in the web evolution.

In 2015, W3C launched a new working group called Web Platform Incubator Community Group (WICG). The purpose of the WICG is:

  • Make it as easy as possible for developers (like us!!) to propose new platform features, in the spirit of the Extensible Web Manifesto.
  • Provide a space where developers and implementers can discuss new platform features.
  • Incubate those ideas by providing guidance and a supportive and inclusive environment to those who have never contributed to standards (and even to those that have!:D); ultimately transitioning those ideas to a W3C Working Group for formal standardization (i.e., making a “W3C Recommendation”).
  • Modernize how we do standardization of platform features
  • Provide a legal framework that keeps all contributions free and open.

Now you know a little bit more about this process, you can probably understand why some things aren’t the way you expected to be or why some features take so long time to land and stabilize.
If you feel like adding your bit to the web, here are a few specification links for important building blocks of the web:

WHATWG — — html5, fetch, dom, compat
WICG — — ResizeObserver, EventListenerOptions, webusb, BackgroundSync
W3C — — ServiceWorker, css-houdini-drafts, webcomponents

Don’t be like Apple, don’t forget to share 😉

Special thanks to Mike Taylor for the support writing this article and for doing a great and inspiring job.

About the author.

Iacami Gevaerd
Iacami Gevaerd

A developer whose comfort zone is the browser console. Likes good old rock&roll and a [cold] one. Enjoys surfing or rock climbing whenever possible.