Part 2: How Browsers work 2 Flashcards
Unlike HTML CSS is a context-free grammar, so its parsing process does not correct mistakes. CSS sourcecode can be parsed using systems we’ve already learned about. Explain this snippet of CSS code:
You are seeing a css ruleset. diverror and a.error are css selectors. The part inside the curly braces represent the rules applied to the ruleset, each rule being a rule declaration.
WebKit uses a bottom up shift-reduce parcer while Firefox uses a top down parser. With both RE’s each entire css file is made into a stylesheet object.
Ok
The web loads synchronously, which means one at a time. When the browser sees as script tag it loads the entire script tag (even if the element is external) before moving on to the next line of code. We have the option of making our scripts part of a defer mode so that the parser reads everything else first before coming back if we’d like. However HTML5 has an option with which we can load our css asynchronously by having CSS load on a different thread
Interesting. How is this done and why?
During the loading of our DOM tree, as our html is being loaded there are three questions I have.
- ) If the web is loaded synchronously and our css link tag is added to the top of the page aren’t CSS stylesheets loaded first even before content? So why all this talk about loading css asynchronously and having issues loading them if seen in script tags?
- ) Are css stylesheets ever loaded using script tags?
- ) Apparently browsers are known to use speculative parsing which is when the browser downloads asyncronously script tag element REFERENCES during the downloading of main content, but leaves official entry into DOM tree to main parser. What does this mean exactly.
- ) How is knowing the following valuable to your codes performance: scripts sometimes ask for styling information when the style is not loaded or parsed yet and this causes issues. Firefoxs Gecko and Chrome, Safari, and Operas Webkit handle this differently. Gecko blocks script downloads if there is a style sheet not yet downloaded. WebKit blocks scripts only when there are style sheets it needs to use that aren’t loaded or parsed yet.
- ) So is the previous question a problem of our placement of css scripts on a page? If we have our css scripts higher up on the hierarchy in the document we don’t have this problem right? What is the scenario in which this becomes a real problem?
Ask mentor!
All this time I thought the DOM tree was created first and then a render tree was formed, but apparently the render tree construction occurs in our RE SIMULTANEOUSLY with the construction of the DOM tree. Really?
Elements in the render tree are called renderer or render object (WebKit) or frames (Gecko).
Ask mentor!
WebKits renderer or render object or in Firefox the frame are all elements of the render tree, these elements when loaded into the render tree have under the hood code that also dictate where in the DOM tree the styling will be positioned as well as how to paint and display the DOM objects the selector items.
Great to know.
The render tree and DOM tree don’t share a one to one relation. Explain.
While the DOM tree has content inside a head script for example the render tree will not show that content, and the render tree also will not show content with styling of display none if the css stylesheet requires that at load time.
Explain the flow of constructing a render tree.
Apparently the render tree is constructed at the same time as the DOM tree, and while the render tree is being constructed it is creating frames and renderers or render objects that match the DOM tree selector elements. Well during this process the act of ‘resolving’ a style is called an attachment! This is a node insertion to the DOM tree of styling, it’s called the node attach method.
Just like the DOM generates a root of the document, the render tree when reading the html and body tag contents generates a root render object. The root of the render tree is what is called the containing block, the top most block that contains all other blocks. Its dimensions are the viewport, the browsers display area, WebKit calls it the renderView, Gecko calls it ViewPortFrame.
So yeah basically the flow of the render tree constructor is that even after lets say your window content is fully loaded, if there should be any style changes needed and any reason to update the render tree, your changes will be sent to the render constructor and it will create a new frame or renderer/render object, which will be ATTACHED to the DOM tree.
Loading of author created stylesheets or user created stylesheets (these exist!?) are all done with the renders tree calculations and attachments. There are two issues when the render tree tries to do its work of styling the DOM tree, what are they.
- ) The style sheet is a very large piece of data, and it is created all at once.
- ) The style sheet must traverse the DOM tree and utilize the selectors.
- ) Applying these rules requires cascading gymnastics or cascade rules that define the hierarchy of these rules.
You should become more acquainted with CSS:
https://developer.mozilla.org/en-US/Learn/CSS/Introduction_to_CSS/Syntax
Know your: inherited properties, non inherited, cascading, etc.
Ok
So one of the issues with CSS is handling the large amount of styling data. Firefox handles this with an engenious thing called a RULE TREE. Explain.
Firefox creates two new trees for easier style computation. A style context tree and a rule tree. WebKit has style objects but they are not stored in a separate tree only the DOM points to the relevant style.
The style context tree is divided into structs and each struct contains style information for a certain category.
If structs have no style definitions we acquire the style definitions from their parents in the context tree.
How valuable is this information to memorize, I mean really?
We can create our css rule sets in one of two ways. Inside our css file or right inside our html document. Either way is fine, but writing our styling inside the html is more direct. However if we choose to write our styling strictly inside the css file, as we should, in order to get even better access to the html elements we use the id and class selectors. What’s interesting about this method.
After parsing the style sheets our rules (css rule sets) are added or attached to one of a several different hash maps according to the selector. There are MAPS by id, by class, by tag name and general (for anything that doesn’t fit in any). So if the selector is an id the rule will be applied to an id map.
The order in which style rules are applied if there is any confusion or the same selector is used twice with different rules are what?
After rules are matched they are sorted according to the cascade rules.
The cascading order goes like this (FROM LOW TO HIGH!!!):
- ) Browser declarations has precedence.
- ) User normal declarations (?)
- ) Author normal declarations
- ) Author important declarations
- ) User important declarations
It seems users really do set their own preferred styles, how common is this and how is it set?
Can you explain specificity in detail?
Ask mentor!
After rules are attached they are sorted according to cascade rules. What does the article mean by WebKit using bubble sort for small lists and merge sort for big ones? Also what does it mean for WebKit to sort by overriding the ‘>’ operator for the rules?
Ask mentor.
