9 ms·

How Browsers Lay Out Web Pages

269 points by pavpanchekha 6y ago

chakspak 6y ago
This tutorial looks amazing. I know what I'm going to be doing the next few weekends.
- bckr 6y ago
  Yes! Apparently it's still being written.... and I NEED them to get to the CSS bits.
  - pavpanchekha 6y ago
    Book author here. A basic styling engine is the very next chapter, so it should be out in about two months, depending on how the writing process goes.
    - bckr 6y ago
      Incredible, thank you! I believe expanding the simple version into a decently robust rendering engine will be the ultimate way for me to learn CSS. Thanks so much again!
- ronsor 6y ago
  No doubt I'll do something crazy, that is, try to implement this in C.
  - peterkos 6y ago
    I was going to > inb4 rust!, but, isn't Gecko built in Rust?
    - ronsor 6y ago
      Gecko is (mostly, at least) traditional C++. Servo is written in Rust.
      - amelius 6y ago
        Would Rust be the best choice of language, given all the back pointers (previous, parent)?
        timw4mail 6y ago
        Trees are not that bad in Rust, it's when you have a cyclical structure that Rust is really difficult.
        amelius 6y ago
        Yes, that's what I meant by "back pointers". In the article, every node has a parent pointer and a child pointer (or several). You can't have both of these pointers without introducing cycles.
    - KwanEsq 6y ago
      The style parts are in Rust, but layout is C++, I believe. servo does have an experimental layout engine (or two? layout 2020?) in Rust, but I don't think that ever reached a point where Mozilla were seriously considering replacing Gecko's with it.
      - timw4mail 6y ago
        I think Servo is basically a proving ground for replacing components in Firefox with Rust equivalents.
- csbartus 6y ago
  Right! I'm working with the web since 2006 but still I find this book a must to read.
- mjgs 6y ago
  It’s such a great idea for a book! I quite like Python but really I want a version all written in NodeJS, so it’s javascript all the way down :)
  - pavpanchekha 6y ago
    Hi mjgs. I'm one of the book's authors, and we debated this quite a bit. The reasoning for using Python is written up here: https://browser.engineering/blog/why-python.html https://browser.engineering/blog/why-python.html That said, it's pretty easy to follow along in JS if you really want and in fact... Stay tuned, there'll be an update in this space very soon.
    - mjgs 6y ago
      Thanks for the reply. I like that you’ve chosen a scripting language, it makes the book much more accessible. If it were in c / c++ / rust etc, I would never read it. Thanks for sending the writeup of why you chose Python. As for javascript readability issues, IMO those are non-issues and actually in some ways beneficial to have one language, no need to context switch. The web workers issue is perhaps a problem, but maybe it makes the implementation easier, even if it doesn’t look much like real browsers? I don’t understand the networking issue you highlight, you can build any networking functionality using NodeJS, it’s actually very good in networked application settings. With so many people that write code online in javascript, the book would be so much more accessible. It would be a great compliment to the Python version or any C / C++ version. I’m interested to hear your update, what’s the best way to get that automatically?
    - mjgs 6y ago
      One other thing...this passed by in my feeds last week, I’m not an expert in web workers or browser threads etc, but it seems like it might be relevant, so sharing it just in case: “A fast, efficient Node.js Worker Thread Pool implementation” https://github.com/piscinajs/piscina https://github.com/piscinajs/piscina
  - deleted 6y ago
    [deleted]
Inityx 6y ago
I wish this web page used a smaller font, 24px (18pt) is really, really large. (HN comments are 9pt.) The page's ToC uses 60% of the body font, which is ~10pt.
- wunderflix 6y ago
  Is there a good page about font sizes, spacings and all that?
  - breck 6y ago
    Here's a fun tool someone shared with me for experimenting with different font params: https://mbarkhau.keybase.pub/readable-text/index.html https://mbarkhau.keybase.pub/readable-text/index.html
    - wunderflix 6y ago
      Awesome! Thank you
- rajangdavis 6y ago
  It's funny you say that, I usually view Hacker News zoomed in at 250% (on desktop) because the font is tinier than I'd like.
  - naavis 6y ago
    Me too, at 200%. My eyes are getting old.
    - davewood 6y ago
      200% club aswell
    - spiralx 6y ago
      My userstyle sets 13pt in a bigger font with lots of line-spacing, looks like I'm in the over 200% crowd :) I can read smaller text for a bit in a single block, but when it's something like a comment section I need things a lot bigger to be able to skim through comments to spot things I'm interested in.
ksec 6y ago
> Elements like <body> and <header> contain blocks stacked vertically. But elements like <p> and <h1> contain text and lay that text out horizontally in lines. ( In European languages, at least! ) Another day, another features despite PDF not being perfect, is still miles ahead of HTML. I am not even sure if there are any intention to bring vertical Japanese subtext feature to HTML.
- nicoburns 6y ago
  HTML/CSS has vertical text https://developer.mozilla.org/en-US/docs/Web/CSS/text-orientation https://developer.mozilla.org/en-US/docs/Web/CSS/text-orient...
- darrenf 6y ago
  > I am not even sure if there are any intention to bring vertical Japanese subtext feature to HTML. Perhaps not HTML itself, but the first draft for writing modes in CSS is over 10 years old: https://www.w3.org/TR/2010/WD-css3-writing-modes-20101202/ https://www.w3.org/TR/2010/WD-css3-writing-modes-20101202/ > This module specifies the text layout model in CSS and the properties that control it. It covers bidirectional and vertical text. There have been numerous revisions in the subsequent years. In 2017 w3.org published this article specifically on using vertical text in paragraphs, forms, lists and tables: https://www.w3.org/International/articles/vertical-text/ https://www.w3.org/International/articles/vertical-text/
helsinkiandrew 6y ago
This is excellent. However much effort I've put in I've always found HTML or rather CSS impenetrable. When doing something a little more complex I will often end up with something that works (or breaks) without fully understanding why. Are there any other good references that give a good underlying understanding of HTML/CSS without just giving examples of the various elements?
- andeee23 6y ago
  Don't have any references for you but maybe I can give some perspective on it. The things that still trip me up with CSS after a few years of full time frontend work are the following: 1. Dynamic 2D stuff CSS kinda sucks for most 2D dynamic layouts. Especially when you have heights that are dependent on widths or the other way around. With CSS grid and the upcoming aspect-ratio things are better but I still run into some limitations in especially dynamic web apps / data visualizations I make and I usually resort to calculating the widths/heights in javascript so I can have full control. 2. Going into the third dimension I'm not a big fan of the z-index / position absolute / relative stuff going on in css. I'm not sure what a better way would look like, but every so often I run into weird issues where a parent somewhere is relative and it messes up an element I'm trying to absolutely position. Most things can be worked around but it's still annoying and usually take longer than what I feel they should. Apart from these, most of the quirks of CSS are very mild and can be worked around easily. I actually find writing CSS quite enjoyable day to day.
- tjoekbezoer 6y ago
  I'd say a good start would be: * Stacking context [1] — how individual layers interact with eachother to form a layout. * Box model [2] — the most important properties that give an individual element its dimensions. [1]: https://tiffanybbrown.com/2015/09/css-stacking-contexts-wtf/ https://tiffanybbrown.com/2015/09/css-stacking-contexts-wtf/ [2]: https://css-tricks.com/the-css-box-model/ https://css-tricks.com/the-css-box-model/
- macspoofing 6y ago
  >Are there any other good references that give a good underlying understanding of HTML/CSS without just giving examples of the various elements? Yeah. The W3C spec. A few years ago (before css flexbox and grid were really a thing), I was in your shoes. Anytime I needed to do something non trivial, I'd have to find some snippet from some tutorial site that would kind of fit with what I was looking for. At some point I got tired of that and just read the W3C specification. That's when I finally got the CSS layout manager. The specification was very accessible and explained exactly the layout rules. For example, here's the spec on the CSS box model: https://www.w3.org/TR/css-box-3/ https://www.w3.org/TR/css-box-3/ Now that flexbox and grid are universally supported in modern browsers, css is actually quite easy.
chris_wot 6y ago
This is excellent, but I also recommend the following that describes how text is laid out of the screen: https://raphlinus.github.io/text/2020/10/26/text-layout.html https://raphlinus.github.io/text/2020/10/26/text-layout.html
deleted 6y ago
[deleted]
londons_explore 6y ago
For those wanting to dive deeper, the layout code in Chromium is surprisingly easy to read considering its a 20+ year old codebase. This is a good starting point: https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/layout/layout_object.h;l=178;drc=bba0186702ff39303c487a012626e5fba8ab42ed;bpv=1;bpt=1 https://source.chromium.org/chromium/chromium/src/+/master:t...
- machello13 6y ago
  How much diverged is this code from WebKit? 20 years ago Blink didn't even exist, right?
  - londons_explore 6y ago
    Most of it. The main changes from WebKit to blink are a different approach to memory allocation (oilpan) and object lifetimes to help security. Most of the main files still say Copyright 1999 **@kde.org showing the origin of the original codebase that hasn't changed much to today. It's now so huge and complex that a major redesign/rewrite is pretty much out of the question. It's still mostly single threaded and all the main objects aren't thread safe. JavaScript shares that thread too. Parts of the rendering are multiththreaded and async, but that's it.
- pavpanchekha 6y ago
  Author here. Yes, the Chromium code is very good, and I learned a lot from reading the Servo code as well. We hope to do some more advanced chapters at the end of the book that reference real browser code bases more directly—if we can find an interesting way to write them, anyway.
jasim 6y ago
> Finally, functional languages tend to fight against large, mutually-linked, mutable data structures, yet the layout engine of a browser is all about that. Is the DOM (and LayoutObject et al.) truly a case where imperative object-oriented programming shines? In pure FP operations like insertion, bidirectional traversal, and moving objects between parents can be cumbersome because there is no implicit identity for the objects. Curious whether this is true, or is there a way to implement a DOM-like API with mostly immutable values?
divan 6y ago
Random thought: why do we still call them "web pages"? They're not hypertext pages anymore and browsers are not hypertext document browsers anymore. (It should probably be called "VM for UI apps that run directly from URL and written in UI stack that has never been intended for UI apps, and has weird tabbed window manager")

269 points by pavpanchekha 6y ago

chakspak 6y ago

This tutorial looks amazing. I know what I'm going to be doing the next few weekends.

bckr 6y ago
Yes! Apparently it's still being written.... and I NEED them to get to the CSS bits.
- pavpanchekha 6y ago
  Book author here. A basic styling engine is the very next chapter, so it should be out in about two months, depending on how the writing process goes.
  - bckr 6y ago
    Incredible, thank you! I believe expanding the simple version into a decently robust rendering engine will be the ultimate way for me to learn CSS. Thanks so much again!
ronsor 6y ago
No doubt I'll do something crazy, that is, try to implement this in C.
- peterkos 6y ago
  I was going to > inb4 rust!, but, isn't Gecko built in Rust?
  - ronsor 6y ago
    Gecko is (mostly, at least) traditional C++. Servo is written in Rust.
    - amelius 6y ago
      Would Rust be the best choice of language, given all the back pointers (previous, parent)?
      - timw4mail 6y ago
        Trees are not that bad in Rust, it's when you have a cyclical structure that Rust is really difficult.
        amelius 6y ago
        Yes, that's what I meant by "back pointers". In the article, every node has a parent pointer and a child pointer (or several). You can't have both of these pointers without introducing cycles.
  - KwanEsq 6y ago
    The style parts are in Rust, but layout is C++, I believe. servo does have an experimental layout engine (or two? layout 2020?) in Rust, but I don't think that ever reached a point where Mozilla were seriously considering replacing Gecko's with it.
    - timw4mail 6y ago
      I think Servo is basically a proving ground for replacing components in Firefox with Rust equivalents.
csbartus 6y ago
Right! I'm working with the web since 2006 but still I find this book a must to read.
mjgs 6y ago
It’s such a great idea for a book! I quite like Python but really I want a version all written in NodeJS, so it’s javascript all the way down :)
- pavpanchekha 6y ago
  Hi mjgs. I'm one of the book's authors, and we debated this quite a bit. The reasoning for using Python is written up here: https://browser.engineering/blog/why-python.html https://browser.engineering/blog/why-python.html That said, it's pretty easy to follow along in JS if you really want and in fact... Stay tuned, there'll be an update in this space very soon.
  - mjgs 6y ago
    Thanks for the reply. I like that you’ve chosen a scripting language, it makes the book much more accessible. If it were in c / c++ / rust etc, I would never read it. Thanks for sending the writeup of why you chose Python. As for javascript readability issues, IMO those are non-issues and actually in some ways beneficial to have one language, no need to context switch. The web workers issue is perhaps a problem, but maybe it makes the implementation easier, even if it doesn’t look much like real browsers? I don’t understand the networking issue you highlight, you can build any networking functionality using NodeJS, it’s actually very good in networked application settings. With so many people that write code online in javascript, the book would be so much more accessible. It would be a great compliment to the Python version or any C / C++ version. I’m interested to hear your update, what’s the best way to get that automatically?
  - mjgs 6y ago
    One other thing...this passed by in my feeds last week, I’m not an expert in web workers or browser threads etc, but it seems like it might be relevant, so sharing it just in case: “A fast, efficient Node.js Worker Thread Pool implementation” https://github.com/piscinajs/piscina https://github.com/piscinajs/piscina
- deleted 6y ago
  [deleted]

Inityx 6y ago

I wish this web page used a smaller font, 24px (18pt) is really, really large. (HN comments are 9pt.) The page's ToC uses 60% of the body font, which is ~10pt.

wunderflix 6y ago
Is there a good page about font sizes, spacings and all that?
- breck 6y ago
  Here's a fun tool someone shared with me for experimenting with different font params: https://mbarkhau.keybase.pub/readable-text/index.html https://mbarkhau.keybase.pub/readable-text/index.html
  - wunderflix 6y ago
    Awesome! Thank you
rajangdavis 6y ago
It's funny you say that, I usually view Hacker News zoomed in at 250% (on desktop) because the font is tinier than I'd like.
- naavis 6y ago
  Me too, at 200%. My eyes are getting old.
  - davewood 6y ago
    200% club aswell
  - spiralx 6y ago
    My userstyle sets 13pt in a bigger font with lots of line-spacing, looks like I'm in the over 200% crowd :) I can read smaller text for a bit in a single block, but when it's something like a comment section I need things a lot bigger to be able to skim through comments to spot things I'm interested in.

ksec 6y ago

> Elements like <body> and <header> contain blocks stacked vertically. But elements like <p> and <h1> contain text and lay that text out horizontally in lines. ( In European languages, at least! ) Another day, another features despite PDF not being perfect, is still miles ahead of HTML. I am not even sure if there are any intention to bring vertical Japanese subtext feature to HTML.

nicoburns 6y ago
HTML/CSS has vertical text https://developer.mozilla.org/en-US/docs/Web/CSS/text-orientation https://developer.mozilla.org/en-US/docs/Web/CSS/text-orient...
darrenf 6y ago
> I am not even sure if there are any intention to bring vertical Japanese subtext feature to HTML. Perhaps not HTML itself, but the first draft for writing modes in CSS is over 10 years old: https://www.w3.org/TR/2010/WD-css3-writing-modes-20101202/ https://www.w3.org/TR/2010/WD-css3-writing-modes-20101202/ > This module specifies the text layout model in CSS and the properties that control it. It covers bidirectional and vertical text. There have been numerous revisions in the subsequent years. In 2017 w3.org published this article specifically on using vertical text in paragraphs, forms, lists and tables: https://www.w3.org/International/articles/vertical-text/ https://www.w3.org/International/articles/vertical-text/

helsinkiandrew 6y ago

This is excellent. However much effort I've put in I've always found HTML or rather CSS impenetrable. When doing something a little more complex I will often end up with something that works (or breaks) without fully understanding why. Are there any other good references that give a good underlying understanding of HTML/CSS without just giving examples of the various elements?

andeee23 6y ago
Don't have any references for you but maybe I can give some perspective on it. The things that still trip me up with CSS after a few years of full time frontend work are the following: 1. Dynamic 2D stuff CSS kinda sucks for most 2D dynamic layouts. Especially when you have heights that are dependent on widths or the other way around. With CSS grid and the upcoming aspect-ratio things are better but I still run into some limitations in especially dynamic web apps / data visualizations I make and I usually resort to calculating the widths/heights in javascript so I can have full control. 2. Going into the third dimension I'm not a big fan of the z-index / position absolute / relative stuff going on in css. I'm not sure what a better way would look like, but every so often I run into weird issues where a parent somewhere is relative and it messes up an element I'm trying to absolutely position. Most things can be worked around but it's still annoying and usually take longer than what I feel they should. Apart from these, most of the quirks of CSS are very mild and can be worked around easily. I actually find writing CSS quite enjoyable day to day.
tjoekbezoer 6y ago
I'd say a good start would be: * Stacking context [1] — how individual layers interact with eachother to form a layout. * Box model [2] — the most important properties that give an individual element its dimensions. [1]: https://tiffanybbrown.com/2015/09/css-stacking-contexts-wtf/ https://tiffanybbrown.com/2015/09/css-stacking-contexts-wtf/ [2]: https://css-tricks.com/the-css-box-model/ https://css-tricks.com/the-css-box-model/
macspoofing 6y ago
>Are there any other good references that give a good underlying understanding of HTML/CSS without just giving examples of the various elements? Yeah. The W3C spec. A few years ago (before css flexbox and grid were really a thing), I was in your shoes. Anytime I needed to do something non trivial, I'd have to find some snippet from some tutorial site that would kind of fit with what I was looking for. At some point I got tired of that and just read the W3C specification. That's when I finally got the CSS layout manager. The specification was very accessible and explained exactly the layout rules. For example, here's the spec on the CSS box model: https://www.w3.org/TR/css-box-3/ https://www.w3.org/TR/css-box-3/ Now that flexbox and grid are universally supported in modern browsers, css is actually quite easy.

chris_wot 6y ago

This is excellent, but I also recommend the following that describes how text is laid out of the screen: https://raphlinus.github.io/text/2020/10/26/text-layout.html https://raphlinus.github.io/text/2020/10/26/text-layout.html

deleted 6y ago

[deleted]

londons_explore 6y ago

For those wanting to dive deeper, the layout code in Chromium is surprisingly easy to read considering its a 20+ year old codebase. This is a good starting point: https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/layout/layout_object.h;l=178;drc=bba0186702ff39303c487a012626e5fba8ab42ed;bpv=1;bpt=1 https://source.chromium.org/chromium/chromium/src/+/master:t...

machello13 6y ago
How much diverged is this code from WebKit? 20 years ago Blink didn't even exist, right?
- londons_explore 6y ago
  Most of it. The main changes from WebKit to blink are a different approach to memory allocation (oilpan) and object lifetimes to help security. Most of the main files still say Copyright 1999 **@kde.org showing the origin of the original codebase that hasn't changed much to today. It's now so huge and complex that a major redesign/rewrite is pretty much out of the question. It's still mostly single threaded and all the main objects aren't thread safe. JavaScript shares that thread too. Parts of the rendering are multiththreaded and async, but that's it.
pavpanchekha 6y ago
Author here. Yes, the Chromium code is very good, and I learned a lot from reading the Servo code as well. We hope to do some more advanced chapters at the end of the book that reference real browser code bases more directly—if we can find an interesting way to write them, anyway.

jasim 6y ago

> Finally, functional languages tend to fight against large, mutually-linked, mutable data structures, yet the layout engine of a browser is all about that. Is the DOM (and LayoutObject et al.) truly a case where imperative object-oriented programming shines? In pure FP operations like insertion, bidirectional traversal, and moving objects between parents can be cumbersome because there is no implicit identity for the objects. Curious whether this is true, or is there a way to implement a DOM-like API with mostly immutable values?

divan 6y ago

Random thought: why do we still call them "web pages"? They're not hypertext pages anymore and browsers are not hypertext document browsers anymore. (It should probably be called "VM for UI apps that run directly from URL and written in UI stack that has never been intended for UI apps, and has weird tabbed window manager")