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?
Don't attach tooltips to document.body
21–30 of 98 posts
Re: Don't attach tooltips to document.body
#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.
Re: Don't attach tooltips to document.body
#23... 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 don't consider this a bug, it's really a very minor performance issue. 80ms isn't going to be noticed by users
Re: Don't attach tooltips to document.body
#24At 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.
Re: Don't attach tooltips to document.body
#25... 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 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 cases.
Last I checked the form additions from HTML5 were still pretty spotty in support, several don't really have a real world use case, and nobody wants to make any more really.
Re: Don't attach tooltips to document.body
#26I am not a UI dev, but I have seen some noise about using Canvas based text rendering. What is HN's opinion on this?
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...
Re: Don't attach tooltips to document.body
#27... 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 don't consider this a bug, it's really a very minor performance issue. 80ms isn't going to be noticed by users
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.
Re: Don't attach tooltips to document.body
#28I am not a UI dev, but I have seen some noise about using Canvas based text rendering. What is HN's opinion on this?
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...
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)
Re: Don't attach tooltips to document.body
#29Earlier quoted context omitted.
I don't consider this a bug, it's really a very minor performance issue. 80ms isn't going to be noticed by users
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.
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
Re: Don't attach tooltips to document.body
#30As for why the parent render tree invalidation is necessary, consider
main:only-child * { /* ... */ }
lots of stuff
When there is (next) sibling wrapper present, anything what happens inside it cannot affect the 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.)