Part 1: How Browsers work Flashcards
WHat is the interwebs?
https://www.youtube.com/watch?v=e4S8zfLdLgQ
The interwebs or the internet is basically just a series a machines that talk to each other through a series of requests of requests and responses. Every computer is a server. Every computer can receive requests or respond, including your PC, but your PC doesn’t have server software so it can’t act as a proper server.
That’s the interwebs.
Explain what the terms UI and UX mean.
UI is an abbreviation or acronym of User Interface, UX is short for User Experience.
The UI encompasses the interface design, the aesthetic design and the information design of a site.
The UX on the other hand encompasses everything from the architecture of the site to how the user is made to feel while using the website.
UX must be layed out first, then the UI.
Let’s go deeper into UI and UX.
WHat do you know about UI?
We know UI points to 3 things (interface, aesthetics, information), but it really points to the practical content of a site and how that content is made easy to use for the user. Period. A good UI takes into account the conversion rate of your site, this speaks to the performance of your site, is your site doing what it was built to do which might be getting users to surf it, use it, or contact you. A good UI organizes content and is easy enough to use, but must also have a great conversion rate, converting visitors into being more active with the site.
So for example you web page has to have information, and has to have some kind of interface but should have some aesthetic design. How you organize those things are its interface. Google.com for example has a completely different interface than Amazon.com, while they both have tons of information available to you they both have a unique face with which that content is seen ( home pages aesthetic design), read (how informational content is displayed), and layout (interface design of both).
The whole conversion rate idea bleeds into UX, so it really sounds more UX to me.
UI: http://www.goodui.org/
Conversion rate: https://qualaroo.com/beginners-guide-to-cro/what-is-conversion-rate-optimization/
UI vs UX: http://blog.careerfoundry.com/ui-design/the-difference-between-ux-and-ui-design-a-laymans-guide/
What do you know about UX, in detail.
UX (acronym for user experience) deals with everthing outside of UI, from the architecture of a site to the feelings users get from using the site. UX designed sites typically falls into one of three experience categories: reactive, magnetic, and immersive experiences.
In reactive exp., websites utilize visitor analytics to create the experience.
In magnetic exp., sites have ecosystems that attract users.
In immersive exp., sites create cult following through being unique.
3 types of UX design: http://incitrio.com/the-three-types-of-ux-design-and-why-they-matter/
The browser! Say the two things a browser is good for?http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ http://rakshasingh.weebly.com/working-of-browser-engine.html
The web client browser mainly serves to display web resources to you, the user. It gets crap and renders crap (I’m just taking ‘walking with einstein’ advice here!).
Browsers can exist on any device equipped to do these thre things (get crap from servers, and display crap). So there are browsers built for laptops, PCs, smart phones, smart watches, and appliances.
The browser acquires web resources (HTML, CSS, images or pdf) from servers and renders them to the browsers window. Note the address bar takes a URL or a uniform resource locator.
The browser! what are the 7 components of a browser.
The browsers 7 components: * the UI (made up of the back/forward, address bar, bookmark menu, window which holds the rendered image) * Network tools (which get the crap we need from servers) * UI backend * 2 engines (rendering engine and browser engine) * JS Interpreter * Data storage
Note that some browsers like Chrome have run multiple different instances of the rendering engine in different tabs at one time.
Explain what the Data Storage component of the browser is and what both engines do.
The Data storage component of the browser acts as the Data Persistence dimension of the browser. This layer of the browser saves important bits locally like cookies. Browsers also support storage mechanisms like localStorage, IndexedDB, WebSQL, and FileSystem. The two ‘engines’ I refer to are the browser engine and the rendering engine. Both work with the UI component of the browser to display content to the screen. The browser engine marshals commands from the UI to the rendering engine. So any user interaction with the back button, address bar, or window will send a command to the browser engine and it might cause a change in the rendering engine. The rendering engine might render a pdf file or it might render html and css parsed content.
The browsers Network, JS interpreter, and UI backend all interact with the UI, browser engine, and rendering engine and data storage/persistence components. How?
The Browsers Network component acquires our packets of data from the servers, it is useful for network calls (HTTP & DNS calls), it is a servant to the rendering engine.
The JS Interpreter is self-explanatory, it interprets and executes JS code for the rendering engine. The JS interpreter serves the rendering engine.
The UI backend is used to draw basic UI widgets like combo boxes (drop down boxes) and windows.
Explain how the rendering engine works to render content to the screen.
The rendering engine has three components of the browser working for it. The Network, the JS Intepreter and the UI Backend. Well the first thing the rendering engine needs to render any content is content, so it will first use the Network tool to pull packets from the outside servers.
2: parse the html and css content it gets to construct a DOM tree.
3: render tree construction (visual elements).
4: setup the trees layout (visual & placement).
5: to paint the rendered tree (RE traverses the RT to style it).
Last thing to know: every browser has its own unique rendering engine. Should I assume everything else within a browser is the same? Do they all use the same Network and Data storage systems?
Explain in more detail the parsing of HTML, CSS and other content into a format it can use to eventually display content to the browser window.
https://www.youtube.com/watch?v=7bs9RGolIyI
Yes, the browser takes the information given it by the server and translates it into something that looks a lot like the image prior, a tree like structure that really just works to organize the code.
Why would parsing of content be necessary? The browser needs to read the code, organize the code and probably apply certain rules and laws to the code to see if nothing is missing.
For example when the browser parses code A + B/C, it reads fine.
When the browser parses A +/ BC it will return errors.
Once the rendering engine (RE) has finished parsing server HTML document content into DOM nodes or a parsing structure, what’s next?
- ) From the starting point of a HTML document, the RE parses the HTML document into a DOM. The DOM is a type of tree structure with nodes (essential step to working inside the DOM) inside a tree we can call call the DOM/content tree. This initial tree holds all our parsed DOM nodes. This current DOM tree is placed in an attachment.
- 5.) If everything fits well in the DOM, the RE does one more thing separately, it parses the CSS and checks to see if it too follows styling laws, it so the CSS styling is joined to our current DOM tree attachment.
- ) Our attachment (DOM nodes and styling queues) now contains visual and informational elements now called a render tree.
- ) The render tree receives layout (positioning and proper size) treatment.
- ) The render tree lastly receives painting/style.
- ) THEN WE GET our display
The JS Interpreter works with the RE to run functionality.
We’ll delve deeper into parsing because it is significant. Each node in a parsed tree or DOM tree, created after the browsers RE reads the sourcecode looks like below, explain.
Each mathematical expression tree node is gotten by the work of our Lexer (or tokenizer) and Parser, the lexical analysis and the syntax analysis.
Each individual token represents a branch, and the connections between them follow syntax rules that connect them together.
Every format you can parse must have deterministic grammar consisting of vocab and syntax rules. This is called context free grammar. More later.
What does it mean for the Parser to iterate while making sense of code? When does the Parser return an exception?
During the lexical and syntax analysis the parser is also making iterative (repeated) checks for whether certain tokens and their organization don’t fit common coding rules.
The parser accepts tokens and constantly tries to match it to a syntax rule, if it can’t match the token to a syntax rule it saves the token for later and will routinely check to see if the token matches a rule. If the Parser is unable to match a token to a rule the Parser will return an exception/error message.
What occurs right after the parse tree is created?
The parse tree is not always the final product, it is sometimes used to create a different type of document all together.
The HTML document is sourcecode, and sometimes the browser may intend to translate this sourcecode to machine code rather than just DOM nodes on a DOM tree. In order for it to reach machine code though the browser will first translate that sourcecode into a parse tree and then turn it into, or compile it into machine readable code.
The parse tree is translated into something else. An example of this is when the browser is called upon to compile a parse tree into machine readable code.
Apparently during the parsing process the language our RE deals with is typically context-free grammar. What does this mean.
https://en.wikipedia.org/wiki/Context-free_grammar
Warning: high level CS topic (awesome)
Human language is not context free, every word we use might mean something different depending on the context. In computer science however there is no context, grammar is used in a highly specific and formalized way. Sourcecode when being read by a Parser follows a production rule which looks like this:
A –> a
The left side is considered a single nonterminal symbol.
The right side is considered a string of terminals and/or nonterminals or can be empty. The symbol on the left side, regardless of context, can be replaced by any property on the right side.
A context free grammar provides a mechanism by which everday phrases can be broken down into blocks of syntax.
Noam Chomsky describes natural language as a mix of context-free grammar rules and transformation rules (sounds like the process a REs parser takes to translate sourcecode to a parse tree and then compile/transform it to machine readable code, in Chomskys case we transform language to human understandable form).
The block structure is FUNDAMENTAL to context-free grammar. This block structure is seen with the implementation of the lexer and parser: the grammar and the syntax rules. These two things create the pieces of code and connect them, making blocks of interrelated code.
So what is the DOM?
The Document Object Model is the first thing created by our parser when it receives sourcecode. It is the object presentation of the HTML document.
The root of the parse tree is the document object, meaning perhaps that the core of the parse tree is the HTML sourcecode. (No duh)
The DOM is also an almost one-to-one copy of the HTML markup. See picture and imagine it in html markup form.
When you think of DOM nodes you must think of them as elements that can be implemented as one of the DOM interfaces.
How does the HTML parser algorithm work?
It consists of two stages: tokenization and tree construction. The tokenization part of the algorithm is the lexical analysis that parses inputs into tokens. Tokens and HTML lexicon/language are really just start tags, end tags, attribute names, atribute values.
This tokenizer part of the algorithm then gives the tokens to the tree constructor.
The html parsing algorithm is described as a state machine. And the states are called insertion modes. Explain.
The html parsing algorithm has two parts: tokenizer and tree constructor. Once the parser is created the DOM tree is also created automatically. The tokenizer sets out consuming tokens from the sourcecode and it transfers those tokens to the tree constructor which plugs the tokens following W3C specs to where they should fit on the DOM tree.
The algorithm itself is a state machine because as the DOM tree is being edited there are several states that occur, or several insertion modes. NOT TO BE CONFUSED with the tokenization algorithm components process of making sense of source code, the tree constructor also operates in modes/states in which it develops the DOM tree in a similar fashion as the tokenizer parses html sourcecode.
The tree structure develops the DOM tree from top to bottom. The first state is the initial mode, receiving the ‘html’ token will cause a move to the before html mode AND a reprocessing of that mode to account for the token entry. This causes the creation of the HTMLHtmlElement element, which is appended to the root Document object.
The state then changes to a new mode, the ‘before head’ mode. Where the parser receives the head token, but even if there are no head tokens this mode is still created, opened and closed by our parser. An in head mode and after head mode occur.
Interestingly there is no before body mode, after the after head mode the parser goes straight to in body mode.
Afterwards we get the after body mode and finally an after after body mode (the html end token) and that concludes our DOM tree construction by the html parsing algorithm.
We then get the EOF token, the end of file.
You’d never see an invalid syntax error message on an html page, why?
We never see an invalid syntax error on an html page because html works to correct any invalid content during parsing and moves on. Different browsers handle their correcting of html.
Well formed documents work smoothly.
Badly formed documents such as below are corrected by the RE.
