10 ms·

Don't attach tooltips to document.body

230 points by atfzl 5y ago

chrismorgan 5y ago
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`. Consider this style rule set which does just what it looks like: head, title, style, script { display: block; }
quickthrower2 5y ago
And Do: profile your web app!
geuis 5y ago
I appreciate these kinds of frontend deep dives.
catmanjan 5y ago
Yet another browser based leaky abstraction... Looking forward to the inevitable trend flip back to native ui!
- jessaustin 5y ago
  Don't hold your breath...
  - quickthrower2 5y ago
    Yes it’s more likely say Microsoft gives up on desktop ui and says meh… use electron!
    - mianos 5y ago
      Like for 'Teams'. But that is probably more of a result of not having a team of developers with a clue and management outnumbering developers five to one. You know it's true when they prioritise Salesforce integration of cut and paste working. Some other major electron apps are pretty OK.
imranghani 5y ago
Really insightful.
ComputerGuru 5y ago
I imagine another option if you need to assign a node to a class and then 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?
TekMol 5y ago
Talking about tooltips: Did anybody get Popper to work as an ES6 module? I tried for a while and gave up.
- FezVrasta 5y ago
  Popper provides ES6 module support out of the box. What problem are you facing with it?
namelosw 5y ago
It's the same reason that most React apps start with ReactDOM.render(<App />, document.getElementById('app')) instead of ReactDOM.render(<App />, document.body). IIRC there were many tutorials in the early days of React that mentioned this.
- chrismorgan 5y ago
  I’d count that as largely unrelated. This is purely a performance optimisation, whereas mounting to an element other than the body is so that you can be somewhat more confident about the DOM inside your chosen root being in the shape you desire, since it’s common for third-party scripts, browser extensions and the likes to add children to the body (start or end), which can mess with VDOM resolution.
- sdflhasjd 5y ago
  That is typically done because some browser extensions and older JS libraries will append elements to the <body>, react would destroy these when rendering.
Agentlien 5y ago
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. 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.
foobar33333 5y ago
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.
- frosted-flakes 5y ago
  And that they don't work on mobile.
  - onion2k 5y ago
    Nor do custom tooltips though because the majority of websites and apps fire them on a mouseover event.
    - mg 5y ago
      Tooltips on mobile are tough. Tooltips usually are on links. For example here on HN, hover over "11 minutes ago" in the comment header and it shows the time. Could this be made available to mobile users? Seems tricky. My first thought would be to show it when the user taps and holds. But that also triggers the browsers default context menu for links. So it would make a murky experience.
      - eknkc 5y ago
        I wonder if a hover over event would be good for UX. I think most of the current displays can detect a finger hovering over the display but not necessarily touching it. It might be a complete disaster though, just wondering how that info could be used.
        frosted-flakes 5y ago
        If used sparingly I think it would be really good. Just for UI hints, not for anything critical. A universal "what is this?" input for anything on the screen.
02020202 5y ago
i wish we could come up with new tech for websites already. this html, css, js, css feels like being stuck in 18th century. just piling one shit spec on another. like, css still cannot do vertical centering to this day. and js had to come up with shadow dom and all that crap to make rendering faster. time to move on.
Aeolun 5y ago
Having worked with React a lot. I could see the invalidation answer coming from a mile away. Glad all that knowledge is useful in different contexts though.
sidcool 5y ago
I am not a UI dev, but I have seen some noise about using Canvas based text rendering. What is HN's opinion on this?
- smrq 5y ago
  Sounds awful. No accessibility to screen readers. It's raster-based so you can't zoom. No text selection or copying. And that's just what I thought of off the top of my head...
  - eitland 5y ago
    Totally agree. There is one reason I can see for using canvas based rendering generally[1] and that is if one really really wants to avoid someone from copy-pasting or indexing the page easily[2]. [1]: valid use cases for using canvas exists. [2]: as someone who has digitized a couple of documents I'd say the effort is just above copy paste (with my tools it is copy, paste, OCR to clipbord, paste, verify)
  - amelius 5y ago
    Shouldn't screen readers use OCR? I mean OCR is basically a solved problem, and there are situations when you want to read what's in an image, or when the HTML is a mess.
    - mhitza 5y ago
      There's more to screen readers than characters, otherwise we wouldn't even need aria attributes. Also OCR is a solved problem if we ban any form of display/script font types.
      - amelius 5y ago
        Yeah, you'll probably get the best experience if the web developer specifically designs for accessibility. I guess the problem is that it doesn't happen as much as we'd like.
- 5y ago
Pxtl 5y ago
... 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.
- weird-eye-issue 5y ago
  I don't consider this a bug, it's really a very minor performance issue. 80ms isn't going to be noticed by users
  - fendy3002 5y ago
    It's very minor, but when it happen many times, it'll be noticable. It's proven because author start the investigation. It won't be a problem if the tooltip has delayed appearance by 80ms, but it holds the process. So the site will have a 80ms stutter everytime a tooltip appear.
    - weird-eye-issue 5y ago
      Which generally won't be noticed but it depends on the site. I'm not saying it isn't an issue just that I wouldn't call it a bug. Certainly not something so bad that it would turn you away from web dev. I mean we even have the tooling to track it down fairly easily
      - Jenk 5y ago
        It's a bug. I don't care for your semantic separation of issue/bug and neither should you. Pointless distinction for the sake of ego protection. It is unwanted behaviour, therefore a bug.
        weird-eye-issue 5y ago
        Alright I guess we will just have to agree to disagree. For me, if an action takes slightly longer than it could take but isn't significantly impacting UX then I don't personally think of that as a bug. Maybe I just don't understand the impact this particular issue had
sandstrom 5y ago
At the bottom of the article they mention: 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. So the tooltip container needs to be hidden with e.g. `display: none`?
- btown 5y ago
  Also curious about this: what creates a "boundary" that prevents an invalid subtree from invalidating the parent? Does it need to be hidden, or simply placed absolutely etc.? The article is so well-researched otherwise that I'm sure the OP knows the answer to this, but it frustratingly didn't make it into the article itself!
- atfzl 5y ago
  Having `display: none` is not required for the tooltip container. The container is an empty div which is not visible, and even after adding children which are not directly visible `inside` this div keeps this container div invisible. You can check out some examples in https://github.com/mui-org/material-ui/issues/27879 https://github.com/mui-org/material-ui/issues/27879
  - sandstrom 5y ago
    Thanks for the update! :) Awesome article btw!
myfonj 5y ago
As for why the parent render tree invalidation is necessary, consider <style> main:only-child * { /* ... */ } </style> <body> <main>lots of stuff </main> </body> 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. 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.)
bserge 5y ago
Wait, you guys use tooltips? Some websites don't even have text accompanying their unintuitive but kewl looking icons. The future is now, old timers!
- foxpurple 5y ago
  Tool tips are bad ui because they are invisible normally and are completely absent on touch inputs. Either use an icon so universal it needs no tip or use text.
  - deleted 5y ago
    [deleted]
faeyanpiraat 5y ago
... Next steps are paint and composting ... That step seems unrelated
- Lvl999Noob 5y ago
  They also weren't discussed. Only mentioned for completeness' sake.
  - faeyanpiraat 5y ago
    I mean it’s a typo. Look up “composting”. I was just joking, the article is excellent.
    - DonHopkins 5y ago
      And all these years I thought composting was using an ActiveX/OLE/XP/COM component like XMLHttpRequest to POST a message to the server. https://wiki.mozilla.org/Gecko:DeCOMtamination https://wiki.mozilla.org/Gecko:DeCOMtamination https://news.ycombinator.com/item?id=22708241 https://news.ycombinator.com/item?id=22708241
      - faeyanpiraat 5y ago
        Ah as in COM Posting.. I have no idea what all this is about though.
habosa 5y ago
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. It's a shame that most of the comments here are just people criticizing web dev frameworks and browsers.
hugneutron 5y ago
The article didn’t seem to mention anything about performance in other browsers, which I find surprising.

230 points by atfzl 5y ago

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`. Consider this style rule set which does just what it looks like: head, title, style, script { display: block; }

quickthrower2 5y ago

And Do: profile your web app!

geuis 5y ago

I appreciate these kinds of frontend deep dives.

catmanjan 5y ago

Yet another browser based leaky abstraction... Looking forward to the inevitable trend flip back to native ui!

jessaustin 5y ago
Don't hold your breath...
- quickthrower2 5y ago
  Yes it’s more likely say Microsoft gives up on desktop ui and says meh… use electron!
  - mianos 5y ago
    Like for 'Teams'. But that is probably more of a result of not having a team of developers with a clue and management outnumbering developers five to one. You know it's true when they prioritise Salesforce integration of cut and paste working. Some other major electron apps are pretty OK.

imranghani 5y ago

Really insightful.

ComputerGuru 5y ago

I imagine another option if you need to assign a node to a class and then 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?

TekMol 5y ago

Talking about tooltips: Did anybody get Popper to work as an ES6 module? I tried for a while and gave up.

FezVrasta 5y ago
Popper provides ES6 module support out of the box. What problem are you facing with it?

namelosw 5y ago

It's the same reason that most React apps start with ReactDOM.render(<App />, document.getElementById('app')) instead of ReactDOM.render(<App />, document.body). IIRC there were many tutorials in the early days of React that mentioned this.

chrismorgan 5y ago
I’d count that as largely unrelated. This is purely a performance optimisation, whereas mounting to an element other than the body is so that you can be somewhat more confident about the DOM inside your chosen root being in the shape you desire, since it’s common for third-party scripts, browser extensions and the likes to add children to the body (start or end), which can mess with VDOM resolution.
sdflhasjd 5y ago
That is typically done because some browser extensions and older JS libraries will append elements to the <body>, react would destroy these when rendering.

Agentlien 5y ago

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

foobar33333 5y ago

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.

frosted-flakes 5y ago
And that they don't work on mobile.
- onion2k 5y ago
  Nor do custom tooltips though because the majority of websites and apps fire them on a mouseover event.
  - mg 5y ago
    Tooltips on mobile are tough. Tooltips usually are on links. For example here on HN, hover over "11 minutes ago" in the comment header and it shows the time. Could this be made available to mobile users? Seems tricky. My first thought would be to show it when the user taps and holds. But that also triggers the browsers default context menu for links. So it would make a murky experience.
    - eknkc 5y ago
      I wonder if a hover over event would be good for UX. I think most of the current displays can detect a finger hovering over the display but not necessarily touching it. It might be a complete disaster though, just wondering how that info could be used.
      - frosted-flakes 5y ago
        If used sparingly I think it would be really good. Just for UI hints, not for anything critical. A universal "what is this?" input for anything on the screen.

02020202 5y ago

i wish we could come up with new tech for websites already. this html, css, js, css feels like being stuck in 18th century. just piling one shit spec on another. like, css still cannot do vertical centering to this day. and js had to come up with shadow dom and all that crap to make rendering faster. time to move on.

Aeolun 5y ago

Having worked with React a lot. I could see the invalidation answer coming from a mile away. Glad all that knowledge is useful in different contexts though.

sidcool 5y ago

I am not a UI dev, but I have seen some noise about using Canvas based text rendering. What is HN's opinion on this?

smrq 5y ago
Sounds awful. No accessibility to screen readers. It's raster-based so you can't zoom. No text selection or copying. And that's just what I thought of off the top of my head...
- eitland 5y ago
  Totally agree. There is one reason I can see for using canvas based rendering generally[1] and that is if one really really wants to avoid someone from copy-pasting or indexing the page easily[2]. [1]: valid use cases for using canvas exists. [2]: as someone who has digitized a couple of documents I'd say the effort is just above copy paste (with my tools it is copy, paste, OCR to clipbord, paste, verify)
- amelius 5y ago
  Shouldn't screen readers use OCR? I mean OCR is basically a solved problem, and there are situations when you want to read what's in an image, or when the HTML is a mess.
  - mhitza 5y ago
    There's more to screen readers than characters, otherwise we wouldn't even need aria attributes. Also OCR is a solved problem if we ban any form of display/script font types.
    - amelius 5y ago
      Yeah, you'll probably get the best experience if the web developer specifically designs for accessibility. I guess the problem is that it doesn't happen as much as we'd like.
5y ago

Pxtl 5y ago

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

weird-eye-issue 5y ago
I don't consider this a bug, it's really a very minor performance issue. 80ms isn't going to be noticed by users
- fendy3002 5y ago
  It's very minor, but when it happen many times, it'll be noticable. It's proven because author start the investigation. It won't be a problem if the tooltip has delayed appearance by 80ms, but it holds the process. So the site will have a 80ms stutter everytime a tooltip appear.
  - weird-eye-issue 5y ago
    Which generally won't be noticed but it depends on the site. I'm not saying it isn't an issue just that I wouldn't call it a bug. Certainly not something so bad that it would turn you away from web dev. I mean we even have the tooling to track it down fairly easily
    - Jenk 5y ago
      It's a bug. I don't care for your semantic separation of issue/bug and neither should you. Pointless distinction for the sake of ego protection. It is unwanted behaviour, therefore a bug.
      - weird-eye-issue 5y ago
        Alright I guess we will just have to agree to disagree. For me, if an action takes slightly longer than it could take but isn't significantly impacting UX then I don't personally think of that as a bug. Maybe I just don't understand the impact this particular issue had

sandstrom 5y ago

At the bottom of the article they mention: 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. So the tooltip container needs to be hidden with e.g. `display: none`?

btown 5y ago
Also curious about this: what creates a "boundary" that prevents an invalid subtree from invalidating the parent? Does it need to be hidden, or simply placed absolutely etc.? The article is so well-researched otherwise that I'm sure the OP knows the answer to this, but it frustratingly didn't make it into the article itself!
atfzl 5y ago
Having `display: none` is not required for the tooltip container. The container is an empty div which is not visible, and even after adding children which are not directly visible `inside` this div keeps this container div invisible. You can check out some examples in https://github.com/mui-org/material-ui/issues/27879 https://github.com/mui-org/material-ui/issues/27879
- sandstrom 5y ago
  Thanks for the update! :) Awesome article btw!

myfonj 5y ago

As for why the parent render tree invalidation is necessary, consider <style> main:only-child * { /* ... */ } </style> <body> <main>lots of stuff </main> </body> 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. 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.)

bserge 5y ago

Wait, you guys use tooltips? Some websites don't even have text accompanying their unintuitive but kewl looking icons. The future is now, old timers!

foxpurple 5y ago
Tool tips are bad ui because they are invisible normally and are completely absent on touch inputs. Either use an icon so universal it needs no tip or use text.
- deleted 5y ago
  [deleted]

faeyanpiraat 5y ago

... Next steps are paint and composting ... That step seems unrelated

Lvl999Noob 5y ago
They also weren't discussed. Only mentioned for completeness' sake.
- faeyanpiraat 5y ago
  I mean it’s a typo. Look up “composting”. I was just joking, the article is excellent.
  - DonHopkins 5y ago
    And all these years I thought composting was using an ActiveX/OLE/XP/COM component like XMLHttpRequest to POST a message to the server. https://wiki.mozilla.org/Gecko:DeCOMtamination https://wiki.mozilla.org/Gecko:DeCOMtamination https://news.ycombinator.com/item?id=22708241 https://news.ycombinator.com/item?id=22708241
    - faeyanpiraat 5y ago
      Ah as in COM Posting.. I have no idea what all this is about though.

habosa 5y ago

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. It's a shame that most of the comments here are just people criticizing web dev frameworks and browsers.

hugneutron 5y ago

The article didn’t seem to mention anything about performance in other browsers, which I find surprising.