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

51–60 of 98 posts

Re: Don't attach tooltips to document.body

#51

Post by jcelerier »

weird-eye-issue wrote: post #47
boredtofears wrote: post #33

Earlier quoted context omitted.

this is exactly why SPA's get a bad rep: developers think an 80ms delay on a minor render operation is acceptable

You might be surprised just how fast 80ms really is. Again I'm not saying this shouldn't be addressed if it's causing noticeable issues but labeling it as a bug just seems strange to me (but that label wouldn't change the priority for me by itself)

> You might be surprised just how fast 80ms really is.

it's, like, five frames on a slow monitor. missing a single frame is already bothersome and worthy of bug reports.

Re: Don't attach tooltips to document.body

#52

Post by smarkov »

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.

https://www.samsung.com/global/galaxy/what-is/air-view/

This is about the best and most intuitive solution you could come up with to this problem. Sadly I believe the Samsung Galaxy S4 was the only phone that supported this without an S Pen so you could simply hover over the screen with your finger. I wish it was a standard feature on all phones.

Re: Don't attach tooltips to document.body

#53

Post by weird-eye-issue »

jcelerier wrote: post #51
weird-eye-issue wrote: post #47

Earlier quoted context omitted.

You might be surprised just how fast 80ms really is. Again I'm not saying this shouldn't be addressed if it's causing noticeable issues but labeling it as a bug just seems strange to me (but that label wouldn't change the priority for me by itself)

> You might be surprised just how fast 80ms really is. it's, like, five frames on a slow monitor. missing a single frame is already bothersome and worthy of bug reports.

It's noticeable if something is moving because that won't look smooth. But a 80ms delay will be very hard to notice. An average reaction time is around 300ms.

With all the downvotes I'm getting I might be missing something though :P

Re: Don't attach tooltips to document.body

#54

Post by amelius »

mhitza wrote: post #49
amelius wrote: post #36

Earlier quoted context omitted.

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.

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.

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.

Re: Don't attach tooltips to document.body

#55

Post by eloisius »

weird-eye-issue wrote: post #53
jcelerier wrote: post #51

Earlier quoted context omitted.

> You might be surprised just how fast 80ms really is. it's, like, five frames on a slow monitor. missing a single frame is already bothersome and worthy of bug reports.

It's noticeable if something is moving because that won't look smooth. But a 80ms delay will be very hard to notice. An average reaction time is around 300ms. With all the downvotes I'm getting I might be missing something though :P

You're not wrong about 80ms being a "small" amount of time, but you're saying that in absolute terms. Native UI tool kits for decades now have targeted The sum total of ignoring this kind of performance footgun is why apps like Slack feel so crappy. You can't get into the flow because it's a pile of high-latency, asynchronous interactions. I haven't used Photoshop in a long time, but back in the early 2000s even on my Compaq with 32MB of RAM it was snappy. I can't imagine using something as complex as Photoshop built as an Electron SPA and keeping my sanity.

[1] https://stackoverflow.com/questions/536300/what-is-the-short...

Re: Don't attach tooltips to document.body

#56

Post by [deleted] »

foxpurple wrote: post #45
bserge wrote: post #35

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!

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]

Re: Don't attach tooltips to document.body

#57

Post by nikanj »

amelius wrote: post #32
zerocrates wrote: post #25

Earlier quoted context omitted.

I really wish we'd gotten a couple more useful native controls back when there was any will to add that kind of stuff... It's sad/annoying to see all this reimplementation of simple stuff like comboboxes, and then all this extra effort to make it work OK in different form factors... The great experience of the select element that just gets you a mobile appropriate native UI for free is unavailable for so many simple…

The "problem" with native controls is that they might visually clash with the design of your website. That's why everybody implements their own controls or uses libraries like jQuery. And sadly, that's probably why we don't have good default controls.

People use JS to implement basic things like scrolling a page, usually resulting in a experience that’s uniformly worse than the native one would be

Re: Don't attach tooltips to document.body

#58

Post by jcelerier »

weird-eye-issue wrote: post #53
jcelerier wrote: post #51

Earlier quoted context omitted.

> You might be surprised just how fast 80ms really is. it's, like, five frames on a slow monitor. missing a single frame is already bothersome and worthy of bug reports.

It's noticeable if something is moving because that won't look smooth. But a 80ms delay will be very hard to notice. An average reaction time is around 300ms. With all the downvotes I'm getting I might be missing something though :P

> An average reaction time is around 300ms.

just because human's reactions are slow, does not mean that humans do not notice. In music it's routine to have people complain when latency goes above 15 ms and it was recently shown that humans could notice in some physiological way down to half a millisecond of latency.

Re: Don't attach tooltips to document.body

#59

Post by qwertox »

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.

I am trying to implement drag and drop of raw text and html (html is mostly Vue components) inside contenteditable="true" to move it around. Like in a WYSIWYG editor.

It is insane how complicated this is. Then you need to consider the differences between browsers. Ultimately you have to start using a library. And integrate that library with the framework and then hope that the framework won't have a major technical overhaul like Angular or Vue had.

Most of the time you just sit there thinking what will be the best approach and start to get more demotivated the more you dig deeper into it.

It is hard.

CKEditor would have solved most of my issues, but their licensing is absolutely crazy. I'd have to contact them to get an offer to use it for normal internet usage, but if I don't know if it will work, and if the site will be a success, then it simply does not make sense to contact them. 37 USD for 25 users? Or getting a custom contract where I don't know how they will change it in the future? I don't understand what assumptions they have about the usage of their editor, but just embedding it into a blog or something similar, where you don't really know how many users you will have, definitely isn't one of them.

Re: Don't attach tooltips to document.body

#60

Post by sdflhasjd »

namelosw wrote: post #11

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

That is typically done because some browser extensions and older JS libraries will append elements to the , react would destroy these when rendering.
Post reply on HN