Let's build a browser engine Part 3: CSS | Hacker News Reader

Let's build a browser engine Part 3: CSS

limpet.net

Part 1 of this series contains a link to an article called "How browsers work" (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.

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

It also reminds me of the military quote, "Amateurs study tactics, professionals study logistics."

> Good programmers worry about data structures and their relationships

Which is precisely what Category Theory is all about.

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.

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.

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

I am excited to hear "sandboxing" in this context. Does rust have sandboxing by any chance on the roadmap?

Servo does.

As much as i love anything that aids fighting the complexity, i think that it's best to address the root cause.

That said, i don't have any strategy at hand regarding browser complexity, but i believe as it gets more prominent, the change will come. At least i hope that the browser i'll be running in 5 years would be a saner piece of software.

Yes, it feels like it's only getting more complex and for the sake of somewhat limited use cases (like your basic JSON/HTML editor apps, or displaying data fastly).

What I'd like to see is support for more general, compiler supporting infrastructure. A platform where you could develop your domain specific languages and data structures that are then transformed to native environment. Kind of like JavaScript is used as a transpiler target, but you still need to have loads of functionality on top of browser base.

Then there could be ways to tag your data with semantics (this text is a heading, this is a link), accessibility, editorial intents (text select, copy/paste) that browser could use to display for specific devices and provide interaction (typing, touch).

Since browser is a place to present and produce almost everything digital, not one standard body nor a standard can provide this. HTML/JS/CSS was borne into what it is today for few, narrowly scoped purposes and is creakingly, laboriously converted into different thing each time you open a web app.

>>> There's really not much "choice" in browsers anymore.

As a web developer, this is actually something that's good for my industry. What I don't need is more choices in browsers, more quirks I need to know and more issues to deal with across a multitude of platforms.

Sure, it's getting better. However, I hardly see a day in the near future where you can code something once and it works perfectly across every single browser.

It would probably be great for you if there was only one browser, but horrible for the Internet as a whole to be so homogeneous. HTML and CSS were designed to allow different browsers to interoperate, specifically so that users could have a choice. The fact is that in a heterogeneous environment, not every browser will behave the same, and that is what web developers should accept. Instead of trying to make pages exactly the same in all browsers, the goal should be to make the informational content accessible. Even the CSS standard has provisions for user stylesheets.

I know this will not work for everything, especially app-like sites; but if web developers would do this for sites whose purpose is to provide information -- which is arguably one of the main goals of the Internet; then maybe it would be a better experience for all browsers, and we wouldn't have such absurdities as static pages that require JS to display.

> With WebKit and Gecko being used by the majority of open-source browsers

Blink is not WebKit just as WebKit is not KHTML.

That's a pretty archaic point. Blink and WebKit remain extremely similar, Blink is almost "WebKit-lite." Google remains one of WebKit's major contributors even after Blink since they share the majority of the same codebase.

The person above is correct, most open-source browsers use some WebKit based engine OR Gecko. The differences between WebKit, Blink, and to a less extent KHTML don't change that fact. They're still the same core-codebase.

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

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.

Reply on news.ycombinator.com