This is an excellent and technically deep post, I learned a lot reading it and I'm going to make sure I'm using my tooltips properly.<p>It's a shame that most of the comments here are just people criticizing web dev frameworks and browsers.
This issue of needlessly forcing the system to recalculate a tree of positions and bonds is also common in other UI contexts such as desktop applications and game UIs.<p>In fact, in games it also happens with the transforms of objects and has been the cause of a number of performance issues during development of AAA games I've been part of.
... this post perfectly encapsulates why I hate web development. A painful and easy to miss bug when trying to reimplement a GUI feature that's been available in every decent GUI framework for over two decades.
As for why the parent render tree invalidation is necessary, consider<p><pre><code> <style>
main:only-child * { /* ... */ }
</style>
<body>
<main>lots of stuff </main>
</body>
</code></pre>
When second node is appended to <body> our CSS selector no longer matches so the rule stops being applied and content of the <main> is no longer styled.<p>When there is (next) sibling wrapper present, anything what happens inside it cannot affect the <main> in our example: in CSS there simply is currently no way to target element according it's next sibling inner structure. (There is one for previous sibling: `prev:empty + next {}`: when prev stops being empty, rule stops to match.)
It would be nice if the browser title text feature didn't flat out suck. Why is there no way to show tooltips immediately rather than having to wait a few seconds. Seems like every website reimplements them because the browser ones are useless.
A remark on the two diagrams following “Then the CSS is parsed and browser creates the CSSOM (CSS Object Model)”: they show body as the root, but would be more accurate if they showed html as be the root and head as hidden by `display: none`.<p>Consider this style rule set which does just what it looks like:<p><pre><code> head,
title,
style,
script {
display: block;
}</code></pre>
I imagine another option if you need to assign a node to a class and <i>then</i> measure its size/location (which is probably quite often) that you can basically take some preliminary/initial values, attach the class, and use an onresize handler to trigger a remeasurement once the reflow has completed at a pace of the browser’s own choosing?
At the bottom of the article they mention:<p><pre><code> What happened here? The tooltip was attached to the tooltip container and not to the body.
This invalidated a much smaller subtree, which was the tooltip container. The tooltip container
is not visible in the page, so modifying it doesn’t invalidate the complete page render tree.
If the tooltip container would have been visible in the page, then the complete render tree
would be invalidated but in this case only an independent subtree was invalidated.
</code></pre>
So the tooltip container needs to be hidden with e.g. `display: none`?
It's the same reason that most React apps start with ReactDOM.render(<App />, document.getElementById('app')) instead of ReactDOM.render(<App />, document.body).<p>IIRC there were many tutorials in the early days of React that mentioned this.
Having worked with React a lot. I could see the invalidation answer coming from a mile away.<p>Glad all that knowledge is useful in different contexts though.
Wait, you guys use tooltips?<p>Some websites don't even have text accompanying their unintuitive but kewl looking icons.<p>The future is now, old timers!