
Let's build a browser engine Part 3: CSS - TheHydroImpulse
http://limpet.net/mbrubeck/2014/08/13/toy-layout-engine-3-css.html
======
oxymoron
Part 1 of this series contains a link to an article called "How browsers work"
([http://www.html5rocks.com/en/tutorials/internals/howbrowsers...](http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/)),
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
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
It also reminds me of the military quote, "Amateurs study tactics,
professionals study logistics."

------
userbinator
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
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
> 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
I am excited to hear "sandboxing" in this context. Does rust have sandboxing
by any chance on the roadmap?

~~~
pcwalton
Servo does.

------
bellerocky
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
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.

