How Browsers Lay Out Web Pages
browser.engineering
browser.engineering
Are there any other good references that give a good underlying understanding of HTML/CSS without just giving examples of the various elements?
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.
* 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/
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/
Now that flexbox and grid are universally supported in modern browsers, css is actually quite easy.
I wrote up this guide about CSS floats, for example: https://pavpanchekha.com/blog/css-floats.html It is just about complete, but it also took me about a year of work to get that understanding (from reading the spec, reading browser code, trying many many examples) and it lead to a published paper. And even then, it doesn't talk about negative top margins or refer to actual implementations!
This is a good starting point:
https://source.chromium.org/chromium/chromium/src/+/master:t...
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.
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!
I quite like Python but really I want a version all written in NodeJS, so it’s javascript all the way down :)
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.
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?
“A fast, efficient Node.js Worker Thread Pool implementation”
https://raphlinus.github.io/text/2020/10/26/text-layout.html
The page's ToC uses 60% of the body font, which is ~10pt.
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.
I haven’t looked into the best way to write web pages that accommodate zooming, but there is a huge variety in how pages perform as you zoom.
Loads of sites don’t do it properly, where you zoom and all the text and images get squashed in the middle of the page, or where the elements disappear off the side of the page. The other horrid thing is when you zoom and then the text is the right size but you end up having to scroll left to right to read the text.
The best sites perform perfectly at every zoom level, with all the content resizing properly so the reading experience is always pleasant.
I’d love to read some tutorials on how to ensure your website performs in this way. In my opinion it’s one of the signs of a really skill-full developer.
HN is great too: an assortment of pieces of text, having varied lengths and organized into a tree-like hierarchy, warrants tighter typography.
I personally like it around 67%.
I'd prefer most sites have smaller fonts; there's no need to complain about it, though, because browsers allow you to make text smaller pretty easily, as long as the site doesn't go out of its way to deny you that.
The important part is not so much getting the right font size, but making sure the user's browser can change it well enough.
If the content tries to do this on behalf of certain users then site X ends up being 1.5*1.5=2.25x zoomed while site Y ends up being 1.5*.66 = 1x zoomed effectively turning a single setting that solved the accessibility and preference problem for everyone into a per content-piece nightmare again. Font size/weight/settings in a design is meant to change relative proportions of a design (e.g. headers, emphasized words, side notes) not to act as the overall scaler for the user - that's already available out of the box.
If this post weren't how browsers lay out web pages I wouldn't be such a stickler but to ignore this is to throw out the main advantage of the sizing model browsers use.
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?
(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")
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.
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/
> 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/