How do browsers read and interpret CSS?
Yes, browsers have a CSS interpreter built in. The reason you don't "wait until window.onload" is because while Javascript is a Turing-complete imperative programming language, CSS is simply a set of styling rules that the browser applies to matching elements it encounters.
CSS rendering is an interesting topic and all the competitors are thriving hard to speed up the view layer (HTML and CSS) rendering to deliver the best results to the end users at a blink of an eye.
Firstly, yes different browsers have their own CSS parser/Rendering engines
- Google Chrome, Opera (from version 15) - Uses Webkit fork called Blink Rendering engine
- Safari - uses Webkit (Now forked to Webkit2)
- Internet Explorer - uses Trident Rendering engine. (+ Update: Edge on Windows 10 uses Chromium fork for its future versions)
- Mozilla firefox - Uses Gecko
All these rendering engine contain both CSS interpreter and HTML DOM parser.
All these engines follow below listed models , these are the set of W3C standard
- Visual processing Model
- Box Model
- CSS 2.1 Addressing Model
Note: All these models are interlinked and interdependent. They are not separate models defining standards to render the CSS. These models shed light on how CSS is processed based on precedence like inline styling, Specificity etc.
Explanation:
Stage 1:
All the browsers download the HTML and CSS script from the server and start off by parsing HTML tags to DOM nodes in a tree called content tree.
While the HTML doc being parsed browser rendering engines construct another tree called the Render tree. This tree is of visual elements in the order in which they will be displayed.
Firefox call it as frames where as Webkit guys call them as Renderer or Renderer object.
See the below image: (Source: HTML5 Rocks)
Stage 2:
After the above process both these tree goes through Layout process meaning the browser tells the viewport where each node has to be placed on the screen.
This is defined as positioning scheme by W3C(Follow this link for detailed info) which instructs the browser on how and where elements are to be placed. Below are the 3 types.
- Normal Flow
- Floats
- Absolute position
Stage 3:
Now the final stage called Painting. This is a gradual process where the rendering engine traverse through each render tree nodes and paint them visually using UI backend layer. At this point all the visual Fx are applied like Font size, Background color, Table painting etc.
Note: This stage can be clearly observed if you try to open any webpage on slow connection. Most modern browsers for better user experience try to display elements as soon as possible. This gives the user an impression that the page is loading and have to wait to complete.
Block diagram of the workflow for better understanding
Source HTML5 Rocks
- Webkit:
- Mozilla's Gecko:
References:(Please read the below links. They are best resources available on the Web pertaining to this topic)
- http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ (Best explaination)
- http://www.slideshare.net/ariyahidayat/understanding-webkit-rendering
- https://html.spec.whatwg.org/multipage/syntax.html#parsing
- http://dbaron.org/talks/2008-11-12-faster-html-and-css/slide-3.xhtml
- https://css-tricks.com/almanac/properties/t/text-rendering/
- https://www.webkit.org/blog/114/webcore-rendering-i-the-basics/
- http://www.w3.org/TR/CSS21/intro.html#addressing
If you've worked with a slow connection anytime recently, you'll find that CSS will be applied to elements as they (slowly) appear, actually reflowing page content as the DOM structure loads. Since CSS is not a programming language, it doesn't rely on objects being available at a given time to be parsed properly (JavaScript), and the browser is able to simply re-assess the structure of the page as it retrieves more HTML by applying styles to new elements.
Perhaps this is why, even today, the bottleneck of Mobile Safari isn't the 3G connection at all times, but it is the page rendering.