Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't attach tooltips to document.body

atfzl.com

Post reply on HN
Print view View original

91–98 of 98 posts

Re: Don't attach tooltips to document.body

#91

Post by croes »

mg wrote: post #19
onion2k wrote: post #17

Earlier quoted context omitted.

Nor do custom tooltips though because the majority of websites and apps fire them on a mouseover event.

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.

>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

The first doesn't exclude the second. That's the way how https://xkcd.com/ is doing it. It just shows both.

Re: Don't attach tooltips to document.body

#92

Post by Pxtl »

AdrianB1 wrote: post #63
Pxtl wrote: post #22

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

Not even a bug, it's one of the inner working things you may or may not know about. I see it more than a trap than a bug. Honestly, there are other parts of IT that have it, the most familiar to me is SQL where you can run the same query in 10 seconds or 20 milliseconds and only experienced DBAs can tune it properly, in many cases without touching the query itself.

Traps are bugs. If you're making a library and you don't treat traps as bugs, it's a bad library.

Re: Don't attach tooltips to document.body

#93

Post by frosted-flakes »

eknkc wrote: post #37
mg wrote: post #19

Earlier quoted context omitted.

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.

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.

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.

Re: Don't attach tooltips to document.body

#94

Post by atfzl »

sandstrom wrote: post #24

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 woul…

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

Re: Don't attach tooltips to document.body

#95

Post by sandstrom »

atfzl wrote: post #94
sandstrom wrote: post #24

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 woul…

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

Thanks for the update! :) Awesome article btw!

Re: Don't attach tooltips to document.body

#96

Post by mrrobotchicken »

qwertox wrote: post #73
lifthrasiir wrote: post #61

Earlier quoted context omitted.

It feels weird to me that you are complaining about the complexity of WYSIWYG editors then proceed to complain the licensing cost of CKEditor which would have solved that very complexity. Wouldn't that mean the complexity of WYSIWYG editors is so high that such a business model works ?

I'm not even sure if it really fits my case, since the editor would need to be able to create Vue components which maintain the reactivity. TinyMCE breaks all reactivity as soon as it "wraps" it all in the editor. CKEditor apparently has a way to do this (up- and downscaling), but there is the very unclear licensing issue. One active user is a user which has used the editor once in a month. So, for example, one which…

I'd suggest you to contact sales to learn the details of custom licensing options if you haven't already, also to make sure you're understanding the active users correctly for your case.

It still offers an open source option so you can test all its limits and see if it fits your case or not. Also if your project is not proprietary there is still the free for open source option in case your project is not compatible with GPL2+.

Re: Don't attach tooltips to document.body

#98

Post by faeyanpiraat »

DonHopkins wrote: post #71
faeyanpiraat wrote: post #70

Earlier quoted context omitted.

I mean it’s a typo. Look up “composting”. I was just joking, the article is excellent.

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://news.ycombinator.com/item?id=22708241

Ah as in COM Posting.. I have no idea what all this is about though.
Post reply on HN