How do browsers read and interpret CSS?
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.
How does the browser know what to read when opening a file on the page
When linking to an external file such as CSS or JS, the browser loads and interprets the files in the order that they are listed in the HTML page.
With regard to the why a CSS file appears as HTML when loaded by the browser, this is because of how web browsers are programmed to work. A browser isn't meant to display a raw CSS or JS file (browsers are meant to load the files into memory and execute actions baed on the code), so as a work around most browsers will load the contents of the CSS or JS file as the body of an HTML page using the <pre> to format the content.
How can a browser know the scss files?
You can read this article for more about Sourcemaps: https://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
This is mainly used for debugging and most of the times is stripted from production environments (in this case I guess they left it for people to check the actual source code and learn as you did :P)
When and how do browsers render style tag in body ?
TL;DR:
In short, the answer to your question is: once a <style> tag is met inside <body> everything stops and the CSSOM is being rebuilt and re-applied to all existing rendered (painted) content.
Placing <style> tags inside <body> is considered bad practice because it can create FOUC. But if your <style> tag only contains rules for elements placed after it in DOM, placing it in body is perfectly fine, as no FOUC can happen.
The render process of a page is quite complex. But, overly-simplified, here's what happens
<head>is read and CSSOM is built. All CSS is render blocking, unless explicitly specified otherwise by use of@mediaqueries. The non-blocking CSS is still loaded, it's not entirely skipped.- DOM building and CSSOM building are ran in paralel,
but all*<script>execution is deferred until CSSOM has been built (on</head>tag met), at which point all loaded<script>s are ran, blocking DOM building. JS can make changes to CSSOM at this point. - Placing
<style>tags inside<body>interrupts everything (JS execution and DOM building), CSSOM is being updated and applied to the already rendered content, if any. Everything is resumed after.
* On further testing it appears <head> parsing is single threaded. CSSOM building does block javascript execution but it's done is stages, as each <link /> and <style> tags are met (a <script> placed after a <link> will only execute after the <link /> was resolved and applied to CSSOM). <script> tags placed in between CSS resources are not deferred until all CSS resources in <head> are parsed, as I initially thought.
And, of course js can make changes to CSSOM at run time. See this question I asked for more on how js execution is blocked by CSSOM building.
All the above apply to the normal loading, without considering async, which adds a whole new layer of complexity to it.
If you're interested in more details, I recommend going through the Performance chapter of Web Fundamentals, provided by Google.
How do browsers read and interpret CSS?
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.
Why do browsers match CSS selectors from right to left?
Keep in mind that when a browser is doing selector matching it has one element (the one it's trying to determine style for) and all your rules and their selectors and it needs to find which rules match the element. This is different from the usual jQuery thing, say, where you only have one selector and you need to find all the elements that match that selector.
If you only had one selector and only one element to compare against that selector, then left-to-right makes more sense in some cases. But that's decidedly not the browser's situation. The browser is trying to render Gmail or whatever and has the one <span> it's trying to style and the 10,000+ rules Gmail puts in its stylesheet (I'm not making that number up).
In particular, in the situation the browser is looking at most of the selectors it's considering don't match the element in question. So the problem becomes one of deciding that a selector doesn't match as fast as possible; if that requires a bit of extra work in the cases that do match you still win due to all the work you save in the cases that don't match.
If you start by just matching the rightmost part of the selector against your element, then chances are it won't match and you're done. If it does match, you have to do more work, but only proportional to your tree depth, which is not that big in most cases.
On the other hand, if you start by matching the leftmost part of the selector... what do you match it against? You have to start walking the DOM, looking for nodes that might match it. Just discovering that there's nothing matching that leftmost part might take a while.
So browsers match from the right; it gives an obvious starting point and lets you get rid of most of the candidate selectors very quickly. You can see some data at http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 (though the notation is confusing), but the upshot is that for Gmail in particular two years ago, for 70% of the (rule, element) pairs you could decide that the rule does not match after just examining the tag/class/id parts of the rightmost selector for the rule. The corresponding number for Mozilla's pageload performance test suite was 72%. So it's really worth trying to get rid of those 2/3 of all rules as fast as you can and then only worry about matching the remaining 1/3.
Note also that there are other optimizations browsers already do to avoid even trying to match rules that definitely won't match. For example, if the rightmost selector has an id and that id doesn't match the element's id, then there will be no attempt to match that selector against that element at all in Gecko: the set of "selectors with IDs" that are attempted comes from a hashtable lookup on the element's ID. So this is 70% of the rules which have a pretty good chance of matching that still don't match after considering just the tag/class/id of the rightmost selector.
Is less interpreted by the browser like CSS?
The example also calls <script src="../../js/less-1.1.3.min.js" type="text/javascript"></script>
Here less-1.1.3.min.js compiles the less from responsive.less to css and return it back to the browser. Also see: http://lesscss.org/#usage
See below you will find the client side compiled CSS between <style id="less:examples-responsive-responsive" type="text/css" media="screen">:
How do browsers process and apply CSS styles to DOM elements?
CSS styles will always be applied from top to bottom, beginning with external stylesheets (in the order they are linked), then styles in the head of the document, then inline styles. Styles later in the hierarchy will overwrite styles that appear earlier.
EDIT: I need to amend my answer. Specificity plays a role as well. The more specifically defined a CSS selector is, the more precedence it takes. Selectors with equal specificity work the way I originally stated.
[ http://coding.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/ ]
EDIT #2: There is actually a good way to calculate the amount of specificity a given set of selectors has that can be found here: [ http://www.htmldog.com/guides/cssadvanced/specificity/ ]
(id selectors) #foo are worth 100
(class selectors) .bar are worth 10
(html selectors) html/body/p/span/div/etc are worth 1
#foo span.bar= 111html body p span = 4
etc
How do browsers parse/render CSS?
To re-implement all that yourself would be totally and utterly insane!
Simply use an HTML/CSS based thingy like webkit (also wrapped inside the Qt framework). Don't do it all again, you'll just make all the same mistakes...
If you want to analyse how webkit handles CSS, the source code is open.
http://www.webkit.org/
http://trac.webkit.org/browser/trunk/Source
Related Topics
Zoom Control and Streetview Not Showing on My Google Map
Continuous CSS Rotation Animation on Hover, Animated Back to 0Deg on Hover Out
How to Prevent a CSS Keyframe Animation from Running on Page Load
How to Decrease Image Brightness in CSS
Select Odd Even Child Excluding the Hidden Child
Div with Cut Out Edges, Border and Transparent Background
CSS Sticky Footers with Unknown Height
Styling Elements with a Dot (.) in the Class Name
Differencebetween Block and Inline-Block with Width: 100%
How to Change the Text Color of First Select Option
When Does CSS's !Important Declaration Not Work
What's the Difference Between CSS3's :Root Pseudo Class and HTML