How web browsers work - Arnau Camprubí

Arnau Camprubí

How web browsers work

A few years ago, I started going down the rabbithole of browser engines. I wanted to write one, so I started looking for resources. None were as detailed as I had hoped. So, I decided to simply read the official specification (rather, the set of interleaved specifications). Understanably, the spec didn’t explain how a browser engine works, just what its result should be. So I started designing a browser engine – just to find out some time later that my design was horrible from the beginning. Well… I restarted the entire project from scratch more than 10 times .<br>The current iteration has lasted for half a year so far, and I’m still confident it is the right design. Finally, I feel perpared to write something I wish existed when I started: an explanation of how browsers actually work .<br>The browser and the browser engine<br>A browser and a browser engine are two distinct things. The program you install on your computer is the browser. It is composed of two parts: the chrome (not to be confused with the browser of the same name) and the browser engine.<br>The browser engine is the part that parses HTML, does layout or runs JS, whereas you can think of the chrome as “the UI”. The browser engine doesn’t know anything about tabs, windows or downloads, those are all part of the chrome. For example, Firefox, Chrome or Opera are browsers. Blink, WebKit or Gecko are browser engines. This post will be centered around the browser engine, since it’s the core of the browser (and the interesting part).<br>The main pipeline<br>The main task for the browser engine is transforming an HTML source into a drawable page. The output of this whole pipeline will be a draw list or display list. It is a list of simple commands like “draw a rectangle of color C at position (X,Y) and of size W by H”. But doing this directly would be absurdly hard. So we split it into simpler tasks, forming a pipeline.

A diagram of the browser engine pipeline<br>I will explain, one by one, each of the components of the pipeline.<br>HTML tokenizer<br>The HTML tokenizer takes HTML source (text) as input and returns a list of tokens. Tokens are the most basic syntactic units. A comment is a token, a tag is a token, text is a token, etc. As an example, the following HTML source would be tokenized as follows:<br>html><br>body><br>div id="foo"><br>Hello world<br>div><br>body><br>html>

Doctype token<br>Start tag token for html (no attributes)<br>Start tag token for body (no atrributes)<br>Start tag token for div (with id="foo")<br>Text token "Hello world"<br>End tag token for div<br>End tag token for body<br>End tag token for html<br>It is usually a simple state machine, following the spec.<br>HTML parser<br>The HTML parser (sometimes called the tree constructor) takes tokens as input and generates a DOM (Document Object Model). It does this by first creating an empty DOM and, for each token, modifying it incrementally. Again, this is pretty well-defined in the spec. The code from before would generate a DOM similar to:<br>Documenthtmlbodydiv#text "Hello world"

Notice that it is in this step that structure is introduced. The DOM is where elements live, and where modifications from javascript happen (causing a cascading effect onwards).<br>CSS tokenizer and parser<br>With the CSS sources we found in the DOM () and the ones included in the browser (the so-called user agent CSS) we do a process similar to the HTML tokenizer and parser. We obtain a CSSOM (CSS Object Model).<br>Style engine<br>This stage takes the DOM and CSSOM and combines them, by computing the style properties for every element, producing the style tree. Think of the style tree as a DOM with extra information for each element.<br>This is where CSS selector matching is checked. If we have a rule like .foo { color: red }, it will modify the color property of each element with the class foo. Other elements will have the default value for that property.<br>Box generation<br>Elements are an abstract concept of the DOM. Boxes, on the other hand, are “physical” boxes. You can think of them as rectangles with size, position, etc. But before we can give them size and position values, we need to generate the boxes. From the style tree, we create a layout tree, where nodes are boxes. Generally, an element translates into a single box. But it’s not always the case. For example, an element with display: none generates no box at all (and neither do their descendants). In some cases, an element can even generate multiple boxes (think of a , it has a “marker” box and a “content” box).<br>Boxes also have padding, margin, border, color, border color, display type (e.g. block or inline), etc. All these properties are derived from the associated style in the style tree. Only the position and size properties are left undefined (for now).<br>Reflow<br>We now have a tree of boxes (the layout tree). Reflow modifies the tree, giving it position and size information, according to a layout scheme. This is probably the most complex stage of the...