5 ms·

Let's build a browser engine Part 3: CSS

deleted 12y ago
[deleted]
oxymoron 12y ago
Part 1 of this series contains a link to an article called "How browsers work" (http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ http://www.html5rocks.com/en/tutorials/internals/howbrowsers...), which I read a while back. The epiphany for me was how browsers combine the DOM with style information into a render tree which can be traversed to do the actual drawing. While I won't be writing a commercial browser any time soon, that was the concept that was missing in mind, and once it was there I felt that I truly did understand the fundamental workings of a web browser and would be able to sit down and write one. This reminds me of the famous Torvalds quote: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." As I have advanced in skill as a programmer, I'm continuously reminded of how true that is. The canonical example at this point is obviously git - which has a mind-blowingly simple albeit clever structure - but I've found it to be the case in almost everything. I'm currently working on a compact DSL for performing a certain type of aggregations across streams of JSON objects. To me, the workings of programming languages used to be a black box with a lot of magic going on. Once I understood the concepts of lexing, parsing, using a visitor to traverse the AST and stack machines, it was went from being out of my reach to a simple but slightly time consuming excercise. There are many other examples -- raytracers, databases, rendering html and css as per the article and so on - but the point is that once you've found a convenient abstraction and a good way to represent the data, tasks that seem complex can become rather easy. A good chunk of what defines a good programmer seems to be the ability/intuition to find those magic abstractions which obliterates the problem.
- arethuza 12y ago
  There is a similar statement in The Mythical Man-Month: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." http://en.wikipedia.org/wiki/The_Mythical_Man-Month http://en.wikipedia.org/wiki/The_Mythical_Man-Month
  - phaedrus 12y ago
    It also reminds me of the military quote, "Amateurs study tactics, professionals study logistics."
- innguest 12y ago
  > Good programmers worry about data structures and their relationships Which is precisely what Category Theory is all about.
userbinator 12y ago
As someone who has been rather disappointed in the direction in which mainstream browsers are going especially most recently, I'm very happy to see articles like this. With WebKit and Gecko being used by the majority of open-source browsers, all with increasingly converging UIs and features (or lack thereof), there's really not much "choice" in browsers anymore. The assumption that browsers need to be extremely complex - maybe this is only partly true - discourages many people from trying to write their own, but it's encouraging to see these attempts at questioning the status quo and writing a minimal browser, because maybe others will also follow. I've also been toying with designing and writing bits of code for a minimal (but still HTML/CSS compliant) rendering engine, although my goal was more to explore the limits of how simple a rendering engine can be while still being useful.
- basiliothecat 12y ago
  I can't stress enough how discouraging is the fact that browsers rely on so complex standard body. And current way they evolve leave little hope. It definitely benefits web in a way, but rising complexity makes for a security nightmare and i wonder how close it brings browsers as a kind of software to limits of sanity and comprehension.
  - pcwalton 12y ago
    > It definitely benefits web in a way, but rising complexity makes for a security nightmare and i wonder how close it brings browsers as a kind of software to limits of sanity and comprehension. Note that this is much of the idea behind Rust (which is used by this series): browsers are too large and difficult for humans to guard against the presence of vulnerabilities, so we use software (i.e. compilers) to do it. Compilers have a much longer attention span than humans do. Sandboxing can also achieve this, although at a much more coarse-grained level.
    - hrjet 12y ago
      I am excited to hear "sandboxing" in this context. Does rust have sandboxing by any chance on the roadmap?
bellerocky 12y ago
Instead of writing your own parser wouldn't you rather want to use a lexer like flex and and a parser generator like bison?
- ffk 12y ago
  I know the author. I asked him a similar question and he replied saying that he wanted it to be a learning experience for himself so he chose to write several components from scratch over bringing in pre-existing libraries.

deleted 12y ago

[deleted]

Part 1 of this series contains a link to an article called "How browsers work" (http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ http://www.html5rocks.com/en/tutorials/internals/howbrowsers...), which I read a while back. The epiphany for me was how browsers combine the DOM with style information into a render tree which can be traversed to do the actual drawing. While I won't be writing a commercial browser any time soon, that was the concept that was missing in mind, and once it was there I felt that I truly did understand the fundamental workings of a web browser and would be able to sit down and write one. This reminds me of the famous Torvalds quote: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." As I have advanced in skill as a programmer, I'm continuously reminded of how true that is. The canonical example at this point is obviously git - which has a mind-blowingly simple albeit clever structure - but I've found it to be the case in almost everything. I'm currently working on a compact DSL for performing a certain type of aggregations across streams of JSON objects. To me, the workings of programming languages used to be a black box with a lot of magic going on. Once I understood the concepts of lexing, parsing, using a visitor to traverse the AST and stack machines, it was went from being out of my reach to a simple but slightly time consuming excercise. There are many other examples -- raytracers, databases, rendering html and css as per the article and so on - but the point is that once you've found a convenient abstraction and a good way to represent the data, tasks that seem complex can become rather easy. A good chunk of what defines a good programmer seems to be the ability/intuition to find those magic abstractions which obliterates the problem.

arethuza 12y ago
There is a similar statement in The Mythical Man-Month: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." http://en.wikipedia.org/wiki/The_Mythical_Man-Month http://en.wikipedia.org/wiki/The_Mythical_Man-Month
- phaedrus 12y ago
  It also reminds me of the military quote, "Amateurs study tactics, professionals study logistics."
innguest 12y ago
> Good programmers worry about data structures and their relationships Which is precisely what Category Theory is all about.

userbinator 12y ago

As someone who has been rather disappointed in the direction in which mainstream browsers are going especially most recently, I'm very happy to see articles like this. With WebKit and Gecko being used by the majority of open-source browsers, all with increasingly converging UIs and features (or lack thereof), there's really not much "choice" in browsers anymore. The assumption that browsers need to be extremely complex - maybe this is only partly true - discourages many people from trying to write their own, but it's encouraging to see these attempts at questioning the status quo and writing a minimal browser, because maybe others will also follow. I've also been toying with designing and writing bits of code for a minimal (but still HTML/CSS compliant) rendering engine, although my goal was more to explore the limits of how simple a rendering engine can be while still being useful.

basiliothecat 12y ago
I can't stress enough how discouraging is the fact that browsers rely on so complex standard body. And current way they evolve leave little hope. It definitely benefits web in a way, but rising complexity makes for a security nightmare and i wonder how close it brings browsers as a kind of software to limits of sanity and comprehension.
- pcwalton 12y ago
  > It definitely benefits web in a way, but rising complexity makes for a security nightmare and i wonder how close it brings browsers as a kind of software to limits of sanity and comprehension. Note that this is much of the idea behind Rust (which is used by this series): browsers are too large and difficult for humans to guard against the presence of vulnerabilities, so we use software (i.e. compilers) to do it. Compilers have a much longer attention span than humans do. Sandboxing can also achieve this, although at a much more coarse-grained level.
  - hrjet 12y ago
    I am excited to hear "sandboxing" in this context. Does rust have sandboxing by any chance on the roadmap?

bellerocky 12y ago

Instead of writing your own parser wouldn't you rather want to use a lexer like flex and and a parser generator like bison?

ffk 12y ago
I know the author. I asked him a similar question and he replied saying that he wanted it to be a learning experience for himself so he chose to write several components from scratch over bringing in pre-existing libraries.