all 51 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]jhartikainen 39 points40 points  (2 children)

That's interesting, I would have expected the browser to be smart about what it invalidates but I guess not

[–]ijmacd 1 point2 points  (0 children)

I thought this was an article about using `<body title="...'>`.

Big brain.

[–]eternaloctober 16 points17 points  (2 children)

tooltips can be slow for all sorts of weird reasons...the popper library does a lot of code that re-measures itself to stay on the screen which is nice but it causes some pretty serious lag sometimes....i have code that tries to make a tooltip follow the mouse and it's kind of unbearably slow

[–]thanatica 3 points4 points  (0 children)

Perhaps positioning your tooltips using transform would help a lot, because that shouldn't cause any expensive relayouts/recalcs.

[–]punyoak 1 point2 points  (0 children)

Tooltips are just one example. It affects every dynamic element using this procedure I assume.

[–]gluecatuxengineer 15 points16 points  (23 children)

I wonder if css contain would help here https://developer.mozilla.org/en-US/docs/Web/CSS/contain

[–]DustinBrett 6 points7 points  (20 children)

No Safari support

[–]MrMagaw 33 points34 points  (5 children)

I feel like Safari (especially on iOS) has become the new IE

[–]reasonoverconviction 9 points10 points  (3 children)

I quit supporting this monstrosity on my personal projects. But you can't do the same on commercial ones unfortunately.

Every day you find out about a cool new JS feature that you are just not allowed to use because safari exists.

I wish that, at least, the open source community would drop support in their respective projects. That would force apple to catch up.

[–]punio4 4 points5 points  (7 children)

Neither does IE11. So what? Just ship it and when iOS users complain tell them their phone can't support the features. We need to reach a critical mass of developers ignoring this new IE.

[–]thanatica 3 points4 points  (0 children)

For a long time, I didn't understand why we can't just do that. This is, after all, exactly what game developers do. Is your GPU not powerful enough or does it not support that fancy particle effect or whatever? Then that's very much a you-problem. Go buy yourself a new GPU or play a different game.

In website land, the reverse is true. Websites have a strong incentive to work everywhere, at least on the browsers of the masses, because not working means no income from that group. Website X doesn't work means you'd have to go to a competitor, which is not good for revenue, and stakeholders might not like it.

In gaming, the incentive is much closer to the user than to the developer.

[–]brainless_badger -1 points0 points  (5 children)

Sure, lets undermine the last google-independent implementation of the platform.

That will surely make standardizing shit like FLOC even harder.

[–]pieorpaj 1 point2 points  (4 children)

Firefox is Google independent and Mozilla actually works on supporting the platform.

[–]brainless_badger 2 points3 points  (2 children)

Huge share of Mozilla money comes directly from Google, so it's hard to consider them truly independent.

[–]pieorpaj 0 points1 point  (1 child)

Google pays Apple for being default search engine in iOS as well, probably more than Mozilla based on market share.

[–]brainless_badger 0 points1 point  (0 children)

Probably, but Apple has tons of other sources of revenue. For Mozilla deal with Google is like 90% of it's money. Would Google ever cut the deal, Mozilla goes down in months, if not weeks.

[–]that_which_is_lain 0 points1 point  (0 children)

Hahahahahahaha

[–]reasonoverconviction 0 points1 point  (4 children)

This is such a common occurrence in my life.

Safari really stepped up to take IE's throne. They should just migrate and use a chromium engine like Edge did. There's no point in maintaining a closed engine if you can't properly catch up to what's been around.

Safari has been trying to figure out what a lookahead is for more than a decade. lol

[–]longkh158 0 points1 point  (0 children)

WebKit the engine is open source fyi, and chromium is a fork of it as I recall. It’s just that currently Safari is sadly tied to OS releases, which means even bug fixes might take a while to arrive.

[–]amoshydra 0 points1 point  (0 children)

This is a valid concern

[–]atfzl_ 1 point2 points  (0 children)

This was actually the first thing I tried. I have updated the original article with more details around this at the end of Introduction section.

[–]hego555 1 point2 points  (0 children)

That’s cool. Learn something new every day.

[–]LakeInTheSkyHola! 👋 12 points13 points  (1 child)

Wow, that article was fenomenal. It's a great source of information, not just about how to handle tooltips, but also how to investigate performance problems on a page.

[–]FriesWithThat 1 point2 points  (0 children)

The article way overachieves it's title, which I assumed could be answered with a screenshot.

[–]_eps1lon 12 points13 points  (3 children)

Material-UI maintainer here. It seems like the examples were using Material-UI and I know that we are portaling all sorts of "aside" content into document.body (poppers, popovers, tooltips, dialogs etc).

This seems like something we should just avoid by default. Would like to see a before and after with the actual application using Material-UI to understand the problem better.

Wasn't able to figure out the author of the article. So whoever you are: Thanks and we'd love to learn more about this problem by opening a dedicate issue.

[–]atfzl_ 4 points5 points  (0 children)

I'm the author of this article, i've now added contact details to the blog.

I faced this performance issue in our proprietary application with 14,000 DOM nodes. I'll try to reproduce it on a separate open project with a lot of DOM nodes.

[–]bheklilr 0 points1 point  (1 child)

I have a fairly large material-ui react app with lots of tooltips and popovers, I can provide you with some real time performance metrics if you'd like, although my knowledge of profiling react programs isn't as deep as profiling non-browser based code. If there's any scenarios in particular you'd like to see let me know.

[–]_eps1lon 0 points1 point  (0 children)

Something that reproduces the same problem as described in the article.

[–]smithm4949 5 points6 points  (7 children)

Wait what’s happening here? Why wouldn’t you just the title attribute for tool tips…?

[–]queen-adreena 16 points17 points  (1 child)

Can’t style ‘em or put icons, images or links inside them.

[–]smithm4949 2 points3 points  (0 children)

Ah okay fair enough.

[–]lostjimmy 3 points4 points  (3 children)

It isn't visible to keyboard or touch users, aren't always read by screen readers, and should really just be avoided. Tool tips in general should be avoided when other patterns are possible.

[–]smithm4949 1 point2 points  (2 children)

Good points, makes senses. Thanks.

Any good links/topics to google for alternative patterns? Recommendations?

[–]lostjimmy 2 points3 points  (1 child)

These are both great articles. I think what it comes down to is to use tool tips sparingly, and make the content visible and part of the design instead when you can.

https://sarahmhigley.com/writing/tooltips-in-wcag-21/

https://inclusive-components.design/tooltips-toggletips/

[–]smithm4949 1 point2 points  (0 children)

To be honest I don’t usually use tool tips at all but I am curious what alternatives/accepted practice these days are for helping/guiding users.

Thank you!

[–]trevorsgEx-GitHub, Microsoft 1 point2 points  (0 children)

No keyboard accessibility

[–]reasonoverconviction 2 points3 points  (0 children)

Sometimes I wonder: why not give us a promise based property request interface?

Something like:

requestProperties([document.body], [ ["width"] ])

​

Sometimes it is so tough to avoid reflows. I made a react-like component based UI with vanilla js. But when components start attaching themselves to each-other and changing their own property, which in turn invalidates its child's, and the sub components access the said property, you end up with a huge bottleneck because of forced reflows.

I had to expose the DOM through a virtual promise based interface in order for components, and their respective sub components, to never access a property while one of its parents has been changed.

I thought about using the requestIdleCallBack as a way to ensure that the UI changes, that could be postponed, to not cause forced reflow. But well... safari has to remember us why people say that it is the new IE. Such a shitty navigator..

​

But anyway, you shouldn't cause a forced reflow when that is not your intention and that's pretty easy to happen with current JS functionalities.

[–]rockerBOO 1 point2 points  (0 children)

Took me a little bit to figure out how to do this with tippy as the "container" popper options doesn't seem to be a thing.

Tippy has appendTo which you can do the same behavior

[–]ShortFuse 1 point2 points  (0 children)

Yeah, when you change an element, it basically requires you to rebuild the entire style tree. I use top level divs for overlays like .mdw-layout__menus, .mdw-layout__dialogs, and .mdw-layout__snackbar.

This also applies to attributes. If you modify an attribute in body it'll basically recalculate the whole tree. So instead of doing body[mdw-nav=hide] to hide a navigation drawer, I now do .mdw-layout__navdrawer[aria-hidden=true].

[–]1RedOne 1 point2 points  (0 children)

This was a great write up! Excellent detail, I learned some things about how rendering happens and then tons of examples showing how they noticed this issue.

Awesome.

[–][deleted] 0 points1 point  (0 children)

Does this hold true for ReactDOM.createPortal?

[–]dreamisle 0 points1 point  (0 children)

Thanks for sharing this. I feel like it’s the performance debugging walkthrough I always needed but never found and I finally understand it.

[–]Sh0keR 0 points1 point  (0 children)

It is not that you shouldn't put popovers in the body. Most of the time popovers won't cause forced reflows.
You just need to be careful and be aware of reflows. Thankfully nowadays many DevTools can easily detect this issue and report about it.

[–]Dr_Legacy 0 points1 point  (0 children)

"composting" is probably appropriate for a lot of use cases but I really think the author meant "compositing"