CSS parser

A web page consists of two separate parts. One part contains the content: headings, text, images, links. The other part contains the styling, i.e. instructions like “this heading is blue and 24 pixels large.” These styling instructions are written in a separate language called CSS, and they initially exist only as text. A CSS parser is the program that reads this text character by character and converts it into an ordered structure. Only then does a string of characters become an instruction that the browser can actually execute.

Why browsers can’t display anything without this step

A computer doesn’t understand text on its own. To it, a CSS file is initially just a long chain of individual characters. The parser gives this chain meaning: here a rule begins, this is the addressed area of the page, this is the property, this is its value. Without this intermediate step, every web page would remain gray and unformatted.

The process also affects how quickly a page builds up. As long as the browser hasn’t yet processed the styling rules, it can’t reliably draw anything. Otherwise it would have to risk displaying the text incorrectly at first and then correcting it right afterward. That’s why, in technical terms, CSS is considered blocking: page rendering waits for the parser. With very large stylesheets, i.e. extensive styling files, this amounts to measurable milliseconds.

A second reason is robustness. CSS is deliberately designed so that errors don’t destroy the entire page. If the parser doesn’t recognize an instruction, it skips exactly that one and continues with the next. That’s why modern web pages still work reasonably well in older browsers instead of failing completely.

From character stream to rule

The work proceeds in two stages. First, the parser breaks the text down into the smallest meaningful units, so-called tokens. A token is, for example, a word, a number, a curly brace, or a semicolon. You can picture this like splitting a sentence into individual words and punctuation marks.

In the second stage, the parser checks how these units belong together. It recognizes that a selector precedes the curly brace, i.e. the specification of which elements on the page are meant. Within the brace, it expects pairs of property and value, separated by a colon. The result is a list of neatly sorted rules in memory.

Only after that does the actual computational work begin. Often several rules apply to the same element, and the browser has to decide which one wins. This evaluation is called the cascade and is no longer the parser’s job. A common misconception is therefore to blame the parser when a color doesn’t take effect. Usually it read the rule correctly; it was simply overridden by a stronger rule.

Where CSS parsers are found

Every browser comes with its own. In Chrome and Edge it sits in the Blink engine, in Firefox in a component called Stylo, in Safari in WebKit. Apps on mobile phones also use such components as soon as they display content from the web. Even an email program that renders a formatted promotional email processes CSS in doing so.

Outside of browsers, parsers work in tools for developers. Programs like Sass or PostCSS read in styling files, modify them automatically, and write back an optimized version. They remove, for instance, superfluous whitespace or add declarations for older browsers. Without a parser, such automatic processing wouldn’t be possible.

In the news, the term mostly comes up in connection with security vulnerabilities. A parser processes data from the internet, i.e. from a source that cannot be trusted. Errors in this processing have already been exploited multiple times to execute foreign code. That’s why parsers are among the most thoroughly tested parts of a browser.