How Browsers Work:Behind the Scenes of Modern Web Browser(I)

Preface

This comprehensive primer on the internal operations of WebKit and Gecko is the result of much research done by Israeli developer Tali Garsiel. Over a few years, she reviewed all the published data about browser internals (see Resources) and spent a lot of time reading web browser source code. She wrote:

In the years of IE 90% dominance there was nothing much to do but regard the browser as a "black box", but now, with open source browsers having  more than half of the usage share, it's a good time to take a peek under the engine's hood and see what's inside a web browser. Well, what's inside are millions of C++ lines...

Tali published her research on  her site, but we knew it deserved a larger audience, so we've cleaned it up and republished it here.

As a web developer, learning the internals of browser operations helps you make better decisions and know the justifications behind development best practices. While this is a rather lengthy document, we recommend you spend some time digging in; we guarantee you'll be glad you did.Paul Irish, Chrome Developer Relations

Introduction

Web browsers are probably the most widely used software. In this primer, I will explain how they work behind the scenes. We will see what happens when you type google.com in the address bar until you see the Google page on the browser screen.

Table of Contents

1. Introduction
   1. The browsers we will talk about
   2. The browser's main functionality
   3. The browser's high level structure
2. The rendering engine
   1. Rendering engines
   2. The main flow
   3. Main flow examples
3. Parsing and DOM tree construction
   1. Parsing - general
      1. Grammars
      2. Parser - Lexer combination
      3. Translation
      4. Parsing example
      5. Formal definitions for vocabulary and syntax
      6. Types of parsers
      7. Generating parsers automatically
   2. HTML Parser
      1. The HTML grammar definition
      2. Not a context free grammar
      3. HTML DTD
      4. DOM
      5. The parsing algorithm
      6. The tokenization algorithm
      7. Tree construction algorithm
      8. Actions when the parsing is finished
      9. Browsers error tolerance
   3. CSS parsing
      1. Webkit CSS parser
   4. The order of processing scripts and style sheets
      1. Scripts
      2. Speculative parsing
      3. Style sheets
4. Render tree construction
   1. The render tree relation to the DOM tree
   2. The flow of constructing the tree
   3. Style Computation
      1. Sharing style data
      2. Firefox rule tree
         1. Division into structs
         2. Computing the style contexts using the rule tree
      3. Manipulating the rules for an easy match
      4. Applying the rules in the correct cascade order
         1. Style sheet cascade order
         2. Specificity
         3. Sorting the rules
   4. Gradual process
5. Layout
   1. Dirty bit system
   2. Global and incremental layout
   3. Asynchronous and Synchronous layout
   4. Optimizations
   5. The layout process
   6. Width calculation
   7. Line Breaking
6. Painting
   1. Global and Incremental
   2. The painting order
   3. Firefox display list
   4. Webkit rectangle storage
7. Dynamic changes
8. The rendering engine's threads
   1. Event loop
9. CSS2 visual model
   1. The canvas
   2. CSS Box model
   3. Positioning scheme
   4. Box types
   5. Positioning
      1. Relative
      2. Floats
      3. Absolute and fixed
   6. Layered representation
10. Resources

1.1The browsers we will talk about

There are five major browsers used today - Internet Explorer, Firefox, Safari, Chrome and Opera. I will give examples from the open source browsers - Firefox, Chrome and Safari (which is partly open source). According to the StatCounter browser statistics, currently (August 2011), the usage share of Firefox, Safari and Chrome together is nearly 60%. So nowadays open source browsers are a substantial part of the browser business.

1.2The browser's main functionality

The browser main functionality is to present the web resource you choose, by requesting it from the server and displaying it on the browser window. The resource is usually an HTML document, but may also be a PDF, image, or other type. The location of the resource is specified by the user using a URI (Uniform resource Identifier).

The way the browser interprets and displays HTML files is specified in the HTML and CSS specifications. These specifications are maintained by the W3C (World Wide Web Consortium) organization, which is the standards organization for the web. 
For years browsers conformed to only a part of the specifications and developed their own extensions. That caused serious compatibility issues for web authors. Today most of the browsers more or less conform to the specifications.

Browsers' user interface have a lot in common with each other. Among the common user interface elements are:

• Address bar for inserting the URI
• Back and forward buttons
• Bookmarking options
• A refresh and stop buttons for refreshing and stopping the loading of current documents
• Home button that gets you to your home page

Strangely enough, the browser's user interface is not specified in any formal specification, it just comes from good practices shaped over years of experience and by browsers imitating each other. The HTML5 specification doesn't define UI elements a browser must have, but lists some common elements. Among those are the address bar, status bar and tool bar. There are, of course, features unique to a specific browser like Firefox's downloads manager.

1.3The browser's high level structure

The browser's main components are (1.1):

1. The user interface - this includes the address bar, back/forward button, bookmarking menu etc. Every part of the browser display except the main window where you see the requested page.
2. The browser engine - marshalls the actions between the UI and the rendering engine.
3. The rendering engine - responsible for displaying the requested content. For example if the requested content is HTML, it is responsible for parsing the HTML and CSS and displaying the parsed content on the screen.
4. Networking - used for network calls, like HTTP requests. It has platform independent interface and underneath implementations for each platform.
5. UI backend - used for drawing basic widgets like combo boxes and windows. It exposes a generic interface that is not platform specific. Underneath it uses the operating system user interface methods.
6. JavaScript interpreter. Used to parse and execute the JavaScript code.
7. Data storage. This is a persistence layer. The browser needs to save all sorts of data on the hard disk, for examples, cookies. The new HTML specification (HTML5) defines 'web database' which is a complete (although light) database in the browser.

    Figure : Browser main components.

It is important to note that Chrome, unlike most browsers, holds multiple instances of the rendering engine - one for each tab. Each tab is a separate process.

Chapter 2

The rendering engine

The responsibility of the rendering engine is well... Rendering, that is display of the requested contents on the browser screen.

By default the rendering engine can display HTML and XML documents and images. It can display other types through a plug-in (or browser extension); for example, displaying PDF using a PDF viewer plug-in. However, in this chapter we will focus on the main use case: displaying HTML and images that are formatted using CSS.

2.1Rendering engines

Our reference browsers - Firefox, Chrome and Safari are built upon two rendering engines. Firefox uses Gecko - a "home made" Mozilla rendering engine. Both Safari and Chrome use Webkit.

Webkit is an open source rendering engine which started as an engine for the Linux platform and was modified by Apple to support Mac and Windows. See webkit.org for more details.

2.2The main flow

The rendering engine will start getting the contents of the requested document from the networking layer. This will usually be done in 8K chunks.

After that this is the basic flow of the rendering engine:

Figure : Rendering engine basic flow.

The rendering engine will start parsing the HTML document and turn the tags to DOM nodes in a tree called the "content tree". It will parse the style data, both in external CSS files and in style elements. The styling information together with visual instructions in the HTML will be used to create another tree - the render tree.

The render tree contains rectangles with visual attributes like color and dimensions. The rectangles are in the right order to be displayed on the screen.

After the construction of the render tree it goes through a "layout" process. This means giving each node the exact coordinates where it should appear on the screen. The next stage is painting - the render tree will be traversed and each node will be painted using the UI backend layer.

It's important to understand that this is a gradual process. For better user experience, the rendering engine will try to display contents on the screen as soon as possible. It will not wait until all HTML is parsed before starting to build and layout the render tree. Parts of the content will be parsed and displayed, while the process continues with the rest of the contents that keeps coming from the network.

2.3Main flow examples

                                   Figure : Webkit main flow

Figure : Mozilla's Gecko rendering engine main flow(3.6)

From figures 3 and 4 you can see that although Webkit and Gecko use slightly different terminology, the flow is basically the same.

Gecko calls the tree of visually formatted elements a "Frame tree". Each element is a frame. Webkit uses the term "Render Tree" and it consists of "Render Objects". Webkit uses the term "layout" for the placing of elements, while Gecko calls it "Reflow". "Attachment" is Webkit's term for connecting DOM nodes and visual information to create the render tree. A minor non-semantic difference is that Gecko has an extra layer between the HTML and the DOM tree. It is called the "content sink" and is a factory for making DOM elements. We will talk about each part of the flow:

 

Chapter 3

3.1Parsing - general

Since parsing is a very significant process within the rendering engine, we will go into it a little more deeply. Let's begin with a little introduction about parsing.

Parsing a document means translating it to some structure that makes sense - something the code can understand and use. The result of parsing is usually a tree of nodes that represent the structure of the document. It is called a parse tree or a syntax tree.

Example - parsing the expression 2 + 3 - 1 could return this tree:

Figure : mathematical expression tree node

3.1.1Grammars

Parsing is based on the syntax rules the document obeys - the language or format it was written in. Every format you can parse must have deterministic grammar consisting of vocabulary and syntax rules. It is called a context free grammar. Human languages are not such languages and therefore cannot be parsed with conventional parsing techniques.

3.1.2Parser - Lexer combination

Parsing can be separated into two sub processes - lexical analysis and syntax analysis.

Lexical analysis is the process of breaking the input into tokens. Tokens are the language vocabulary - the collection of valid building blocks. In human language it will consist of all the words that appear in the dictionary for that language.

Syntax analysis is the applying of the language syntax rules.

Parsers usually divide the work between two components - the lexer (sometimes called tokenizer) that is responsible for breaking the input into valid tokens, and the parser that is responsible for constructing the parse tree by analyzing the document structure according to the language syntax rules. The lexer knows how to strip irrelevant characters like white spaces and line breaks.

Figure : from source document to parse trees

The parsing process is iterative. The parser will usually ask the lexer for a new token and try to match the token with one of the syntax rules. If a rule is matched, a node corresponding to the token will be added to the parse tree and the parser will ask for another token.

If no rule matches, the parser will store the token internally, and keep asking for tokens until a rule matching all the internally stored tokens is found. If no rule is found then the parser will raise an exception. This means the document was not valid and contained syntax errors.

3.1.3Translation

Many times the parse tree is not the final product. Parsing is often used in translation - transforming the input document to another format. An example is compilation. The compiler that compiles a source code into machine code first parses it into a parse tree and then translates the tree into a machine code document.

Figure : compilation flow

3.1.4Parsing example

In figure 5 we built a parse tree from a mathematical expression. Let's try to define a simple mathematical language and see the parse process.

 

Vocabulary: Our language can include integers, plus signs and minus signs.

Syntax:

1. The language syntax building blocks are expressions, terms and operations.
2. Our language can include any number of expressions.
3. An expression is defined as a "term" followed by an "operation" followed by another term
4. An operation is a plus token or a minus token
5. A term is an integer token or an expression

 

Let's analyze the input 2 + 3 - 1. 
The first substring that matches a rule is 2, according to rule #5 it is a term. The second match is 2 + 3 this matches the third rule - a term followed by an operation followed by another term. The next match will only be hit at the end of the input.2 + 3 - 1 is an expression because we already know that 2+3 is a term so we have a term followed by an operation followed by another term. 2 + + will not match any rule and therefore is an invalid input.

3.1.5Formal definitions for vocabulary and syntax

Vocabulary is usually expressed by regular expressions.

For example our language will be defined as:

INTEGER  : 0 |[ 1 - 9 ][ 0 - 9 ]*  PLUS  : +  MINUS : - As you see, integers are defined by a regular expression.

 

Syntax is usually defined in a format called BNF. Our language will be defined as:

expression  :=  term operation term operation  :=  PLUS  |  MINUS term  :=  INTEGER  |  expression

 

We said that a language can be parsed by regular parsers if its grammar is a context frees grammar. An intuitive definition of a context free grammar is a grammar that can be entirely expressed in BNF. For a formal definition see Wikipedia's article on Context-free grammar

3.1.6Types of parsers

There are two basic types of parsers - top down parsers and bottom up parsers. An intuitive explanation is that top down parsers see the high level structure of the syntax and try to match one of them. Bottom up parsers start with the input and gradually transform it into the syntax rules, starting from the low level rules until high level rules are met.

Let's see how the two types of parsers will parse our example:

Top down parser will start from the higher level rule - it will identify 2 + 3 as an expression. It will then identify 2 + 3 - 1as an expression (the process of identifying the expression evolves matching the other rules, but the start point is the highest level rule).

The bottom up parser will scan the input until a rule is matched it will then replace the matching input with the rule. This will go on until the end of the input. The partly matched expression is placed on the parsers stack.

Stack	Input
	2 + 3 - 1
term	+ 3 - 1
term operation	3 - 1
expression	- 1
expression operation	1
expression

This type of bottom up parser is called a shift-reduce parser, because the input is shifted to the right (imagine a pointer pointing first at the input start and moving to the right) and is gradually reduced to syntax rules.

 

3.1.7Generating parsers automatically

There are tools that can generate a parser for you. They are called parser generators. You feed them with the grammar of your language—its vocabulary and syntax rules—and they generate a working parser. Creating a parser requires a deep understanding of parsing and its not easy to create an optimized parser by hand, so parser generators can be very useful.

Webkit uses two well known parser generators - Flex for creating a lexer and Bison for creating a parser (you might run into them with the names Lex and Yacc). Flex input is a file containing regular expression definitions of the tokens. Bison's input is the language syntax rules in BNF format.

3.2HTML Parser

The job of the HTML parser is to parse the HTML markup into a parse tree.

3.2.1The HTML grammar definition

The vocabulary and syntax of HTML are defined in specifications created by the W3C organization. The current version is HTML4 and work on HTML5 is in progress.

3.2.2Not a context free grammar

As we have seen in the parsing introduction, grammar syntax can be defined formally using formats like BNF.

Unfortunately all the conventional parser topics do not apply to HTML (I didn't bring them up just for fun - they will be used in parsing CSS and JavaScript). HTML cannot easily be defined by a context free grammar that parsers need.

There is a formal format for defining HTML — DTD (Document Type Definition) — but it is not a context free grammar.

This appears strange at first sight; HTML is rather close to XML. There are lots of available XML parsers. There is an XML variation of HTML — XHTML — so what's the big difference?

The difference is that HTML approach is more "forgiving", it lets you omit certain tags which are added implicitly, sometimes omit the start or end of tags etc. On the whole it's a "soft" syntax, as opposed to XML's stiff and demanding syntax.

Apparently this seemingly small difference makes a world of a difference. On one hand this is the main reason why HTML is so popular - it forgives your mistakes and makes life easy for the web author. On the other hand, it makes it difficult to write a formal grammar. So to summarize - HTML cannot be parsed easily, not by conventional parsers since its grammar is not a context free grammar, and not by XML parsers.

3.2.3HTML DTD

HTML definition is in a DTD format. This format is used to define languages of the SGML family. The format contains definitions for all allowed elements, their attributes and hierarchy. As we saw earlier, the HTML DTD doesn't form a context free grammar.

There are a few variations of the DTD. The strict mode conforms solely to the specifications but other modes contain support for markup used by browsers in the past. The purpose is backwards compatibility with older content. The current strict DTD is here: www.w3.org/TR/html4/strict.dtd

3.2.4DOM

The output tree - the "parse tree" is a tree of DOM element and attribute nodes. DOM is short for Document Object Model. It is the object presentation of the HTML document and the interface of HTML elements to the outside world like JavaScript. 
The root of the tree is the "Document" object.

The DOM has an almost one-to-one relation to the markup. For example, this markup:

<html> <body> <p>  Hello World  </p> <div> <img src = "example.png" /></div> </body> </html> Would be translated to the following DOM tree:

Figure : DOM tree of the example markup

Like HTML, DOM is specified by the W3C organization. See www.w3.org/DOM/DOMTR. It is a generic specification for manipulating documents. A specific module describes HTML specific elements. The HTML definitions can be found here:www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.html.

When I say the tree contains DOM nodes, I mean the tree is constructed of elements that implement one of the DOM interfaces. Browsers use concrete implementations that have other attributes used by the browser internally.

3.2.5The parsing algorithm

As we saw in the previous sections, HTML cannot be parsed using the regular top down or bottom up parsers.

The reasons are:

1. The forgiving nature of the language.
2. The fact that browsers have traditional error tolerance to support well known cases of invalid HTML.
3. The parsing process in reentrant. Usually the source doesn't change during parsing, but in HTML, script tags containing document.write can add extra tokens, so the parsing process actually modifies the input.

Unable to use the regular parsing techniques, browsers create custom parsers for parsing HTML.

The parsing algorithm is described in detail by the HTML5 specification. The algorithm consists of two stages - tokenization and tree construction.

Tokenization is the lexical analysis, parsing the input into tokens. Among HTML tokens are start tags, end tags, attribute names and attribute values.

The tokenizer recognizes the token, gives it to the tree constructor, and consumes the next character for recognizing the next token, and so on until the end of the input.

Figure : HTML parsing flow (taken from HTML5 spec)

3.2.6The tokenization algorithm

The algorithm's output is an HTML token. The algorithm is expressed as a state machine. Each state consumes one or more characters of the input stream and updates the next state according to those characters. The decision is influenced by the current tokenization state and by the tree construction state. This means the same consumed character will yield different results for the correct next state, depending on the current state. The algorithm is too complex to describe fully, so let's see a simple example that will help us understand the principle.

Basic example - tokenizing the following HTML:

<html> <body>  Hello world  </body> </html>

The initial state is the "Data state". When the < character is encountered, the state is changed to "Tag open state". Consuming an a-z character causes creation of a "Start tag token", the state is change to "Tag name state". We stay in this state until the > character is consumed. Each character is appended to the new token name. In our case the created token is an html token.

When the > tag is reached, the current token is emitted and the state changes back to the "Data state". The <body> tag will be treated by the same steps. So far the html and body tags were emitted. We are now back at the "Data state". Consuming the H character of Hello world will cause creation and emitting of a character token, this goes on until the < of</body> is reached. We will emit a character token for each character of Hello world.

We are now back at the "Tag open state". Consuming the next input / will cause creation of an end tag token and a move to the "Tag name state". Again we stay in this state until we reach >.Then the new tag token will be emitted and we go back to the "Data state". The </html> input will be treated like the previous case.

Figure : Tokenizing the example input

3.2.7Tree construction algorithm

When the parser is created the Document object is created. During the tree construction stage the DOM tree with the Document in its root will be modified and elements will be added to it. Each node emitted by the tokenizer will be processed by the tree constructor. For each token the specification defines which DOM element is relevant to it and will be created for this token. Except of adding the element to the DOM tree it is also added to a stack of open elements. This stack is used to correct nesting mismatches and unclosed tags. The algorithm is also described as a state machine. The states are called "insertion modes".

Let's see the tree construction process for the example input:

<html> <body>  Hello world  </body> </html>

The input to the tree construction stage is a sequence of tokens from the tokenization stage The first mode is the "initial mode". Receiving the html token will cause a move to the "before html" mode and a reprocessing of the token in that mode. This will cause a creation of the HTMLHtmlElement element and it will be appended to the root Document object.

The state will be changed to "before head". We receive the "body" token. An HTMLHeadElement will be created implicitly although we don't have a "head" token and it will be added to the tree.

We now move to the "in head" mode and then to "after head". The body token is reprocessed, an HTMLBodyElement is created and inserted and the mode is transferred to "in body".

The character tokens of the "Hello world" string are now received. The first one will cause creation and insertion of a "Text" node and the other characters will be appended to that node.

The receiving of the body end token will cause a transfer to "after body" mode. We will now receive the html end tag which will move us to "after after body" mode. Receiving the end of file token will end the parsing.

Figure : tree construction of example html

3.2.8Actions when the parsing is finished

At this stage the browser will mark the document as interactive and start parsing scripts that are in "deferred" mode - those who should be executed after the document is parsed. The document state will be then set to "complete" and a "load" event will be fired.

You can see the full algorithms for tokenization and tree construction in HTML5 specification

3.2.9Browsers error tolerance

You never get an "Invalid Syntax" error on an HTML page. Browsers fix any invalid content and go on.

Take this HTML for example:

<html> <mytag> </mytag> <div> <p> </div>  Really lousy HTML  </p> </html>

I must have violated about a million rules ("mytag" is not a standard tag, wrong nesting of the "p" and "div" elements and more) but the browser still shows it correctly and doesn't complain. So a lot of the parser code is fixing the HTML author mistakes.

The error handling is quite consistent in browsers but amazingly enough it's not part of HTML current specification. Like bookmarking and back/forward buttons it's just something that developed in browsers over the years. There are known invalid HTML constructs that repeat themselves in many sites and the browsers try to fix them in a conformant way with other browsers.

The HTML5 specification does define some of these requirements. Webkit summarizes this nicely in the comment at the beginning of the HTML parser class

The parser parses tokenized input into the document, building up the document tree. If the document is well-formed, parsing it is straightforward.

Unfortunately, we have to handle many HTML documents that are not well-formed, so the parser has to be tolerant about errors.

We have to take care of at least the following error conditions:

1. The element being added is explicitly forbidden inside some outer tag. In this case we should close all tags up to the one, which forbids the element, and add it afterwards.
2. We are not allowed to add the element directly. It could be that the person writing the document forgot some tag in between (or that the tag in between is optional). This could be the case with the following tags: HTML HEAD BODY TBODY TR TD LI (did I forget any?).
3. We want to add a block element inside to an inline element. Close all inline elements up to the next higher block element.
4. If this doesn't help, close elements until we are allowed to add the element or ignore the tag.

Let's see some Webkit error tolerance examples:

</br> instead of <br>

Some sites use </br> instead of <br>. In order to be compatible with IE and Firefox, Webkit treats this like <br>. 
The code:

if ( t -> isCloseTag ( brTag ) &&  m_document -> inCompatMode ()) {  reportError ( MalformedBRError );  t -> beginTag  = true ; }Note - the error handling is internal - it won't be presented to the user.

 

A stray table

A stray table is a table inside another table contents but not inside a table cell. 
Like this example:

<table> <table> <tr><td> inner table </td></tr> </table> <tr><td> outer table </td></tr> </table> Webkit will change the hierarchy to two sibling tables:  <table> <tr><td> outer table </td></tr> </table> <table> <tr><td> inner table </td></tr> </table> The code:  if ( m_inStrayTableContent  &&  localName  ==  tableTag )  popBlock ( tableTag ); Webkit uses a stack for the current element contents - it will pop the inner table out of the outer table stack. The tables will now be siblings.

 

Nested form elements

In case the user puts a form inside another form, the second form is ignored. 
The code:

if (! m_currentFormElement ) {  m_currentFormElement  = new HTMLFormElement ( formTag ,  m_document ); }

 

A too deep tag hierarchy

The comment speaks for itself. 

www.liceo.edu.mx is an example of a site that achieves a level of nesting of about 1500 tags, all from a bunch of <b>s. We will only allow at most 20 nested tags of the same type before just ignoring them all together.

bool HTMLParser :: allowNestedRedundantTag ( const AtomicString &  tagName ) { unsigned  i  = 0 ; for ( HTMLStackElem *  curr  =  m_blockStack ;  i  <  cMaxRedundantTagDepth  &&  curr  &&  curr -> tagName  ==  tagName ;  curr  =  curr -> next ,  i ++) { } return  i  !=  cMaxRedundantTagDepth ; }

 

Misplaced html or body end tags

Again - the comment speaks for itself.

Support for really broken html. We never close the body tag, since some stupid web pages close it before the actual end of the doc. Let's rely on the end() call to close things.

if ( t -> tagName  ==  htmlTag  ||  t -> tagName  ==  bodyTag  ) return ; So web authors beware - unless you want to appear as an example in a Webkit error tolerance code snippet - write well formed HTML.

 

 

3.3CSS parsing

Remember the parsing concepts in the introduction? Well, unlike HTML, CSS is a context free grammar and can be parsed using the types of parsers described in the introduction. In fact the CSS specification defines CSS lexical and syntax grammar.

Let's see some examples: 
The lexical grammar (vocabulary) is defined by regular expressions for each token:

comment \/\*[^*]*\*+([^/*][^*]*\*+)*\/num [0-9]+|[0-9]*"."[0-9]+nonascii [\200-\377]nmstart [_a-z]|{nonascii}|{escape}nmchar [_a-z0-9-]|{nonascii}|{escape}name {nmchar}+ident {nmstart}{nmchar}*

"ident" is short for identifier, like a class name. "name" is an element id (that is referred by "#" )

The syntax grammar is described in BNF.

ruleset :  selector  [ ','  S *  selector  ]* '{'  S *  declaration  [ ';'  S *  declaration  ]* '}'  S * ; selector :  simple_selector  [  combinator selector  |  S + [  combinator ?  selector  ]? ]? ; simple_selector :  element_name  [  HASH  |  class  |  attrib  |  pseudo  ]* | [  HASH  |  class  |  attrib  |  pseudo  ]+ ; class : '.'  IDENT  ; element_name :  IDENT  | '*' ; attrib : '['  S *  IDENT S * [ [ '=' |  INCLUDES  |  DASHMATCH  ]  S * [  IDENT  |  STRING  ]  S * ] ']' ; pseudo : ':' [  IDENT  |  FUNCTION S * [ IDENT S *] ')' ] ; Explanation: A ruleset is this structure:  div . error  ,  a . error  { color : red ; font-weight : bold ; } div.error and a.error are selectors. The part inside the curly braces contains the rules that are applied by this ruleset. This structure is defined formally in this definition:  ruleset :  selector  [ ','  S *  selector  ]* '{'  S *  declaration  [ ';'  S *  declaration  ]* '}'  S * ; This means a ruleset is a selector or optionally number of selectors separated by a coma and spaces (S stands for white space). A ruleset contains curly braces and inside them a declaration or optionally a number of declarations separated by a semicolon. "declaration" and "selector" will be defined in the following BNF definitions.

 

3.3.1Webkit CSS parser

Webkit uses Flex and Bison parser generators to create parsers automatically from the CSS grammar files. As you recall from the parser introduction, Bison creates a bottom up shift-reduce parser. Firefox uses a top down parser written manually. In both cases each CSS file is parsed into a StyleSheet object, each object contains CSS rules. The CSS rule objects contain selector and declaration objects and other object corresponding to CSS grammar.

Figure : parsing CSS

3.4The order of processing scripts and style sheets

3.4.1Scripts

The model of the web is synchronous. Authors expect scripts to be parsed and executed immediately when the parser reaches a <script> tag. The parsing of the document halts until the script was executed. If the script is external then the resource must be first fetched from the network - this is also done synchronously, the parsing halts until the resource is fetched. This was the model for many years and is also specified in HTML 4 and 5 specifications. Authors could mark the script as "defer" and thus it will not halt the document parsing and will execute after it is parsed. HTML5 adds an option to mark the script as asynchronous so it will be parsed and executed by a different thread.

3.4.2Speculative parsing

Both Webkit and Firefox do this optimization. While executing scripts, another thread parses the rest of the document and finds out what other resources need to be loaded from the network and loads them. This way resources can be loaded on parallel connections and the overall speed is better. Note - the speculative parser doesn't modify the DOM tree and leaves that to the main parser, it only parses references to external resources like external scripts, style sheets and images.

3.4.3Style sheets

Style sheets on the other hand have a different model. Conceptually it seems that since style sheets don't change the DOM tree, there is no reason to wait for them and stop the document parsing. There is an issue, though, of scripts asking for style information during the document parsing stage. If the style is not loaded and parsed yet, the script will get wrong answers and apparently this caused lots of problems. It seems to be an edge case but is quite common. Firefox blocks all scripts when there is a style sheet that is still being loaded and parsed. Webkit blocks scripts only when they try to access certain style properties that may be effected by unloaded style sheets.