Live data from Hacker News

Don't attach tooltips to document.body

atfzl.com

71–80 of 98 posts

Re: Don't attach tooltips to document.body

#71

Earlier quoted context omitted.

They also weren't discussed. Only mentioned for completeness' sake.

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

Re: Don't attach tooltips to document.body

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

Web makes it super easy to build custom components compared to something like Qt, GtK or even UIKit. One of the reasons why web UIs are common is that people want more than tables buttons and forms.

Re: Don't attach tooltips to document.body

#73
post #59

Earlier quoted context omitted.

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

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 just signs up to check out the service and then does nothing with it ever again and doesn't subscribe.

So if I invest my time into learning this upscaling/downscaling issue, which can get complicated with a Vue component, all this in the context of prototyping the entire app, where the primary functionality gained by CKEditor the ability to enable drag and drop (move) of components as if they were pictures, it seems like overkill, since directly manipulating the DOM to move elements appears to be a a much more simple task.

I've made a test wit ondrag, ondrop and what JavasScript has to offer and it mostly works, but there are some small issues which I just can't resolve and don't know if I can resolve them if I invest more time in that direction.

So currently I'm checking out drag and drop libraries, which mostly seem to fit the purpose, but also have issues.

This is what I was getting at with my initial comment, that it's so hard to make these decisions if the outcome of the paths is so unclear. It's all a struggle between decisions and their tests which need to be made.

Assuming CKEditor would solve the issues for me, then the initial cost would still be to high. That would be different with a stable stream of income, but new services usually don't have that.

Free for up to 5 active users per billing period? This would be take 5 users to just check out the service and then that's it for the rest of the month. 37 USD for 25 active users per billing period? Simply not doable for me in the context of a startup.

> What is the minimum length of subscription-based software licenses? 12 months.

That's 444 USD for 288 potential users which wouldn't get charged more than 2 or 3 USD per month.

Re: Don't attach tooltips to document.body

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

Re: Don't attach tooltips to document.body

#75
post #31
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.

Same here. Got a job to do some java. 6 months later, I had to learn angular. 6 months later I was not in the company anymore. HTML was not designed to be dynamic. There are too many redundant feature of HTML/CSS/JS, and honestly I would make everything obsolete and design a new document format with a open binary format.

[deleted]

Re: Don't attach tooltips to document.body

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

don't agree at all. If the "native thing" came at an overhead, your hands would be tied. If the "native thing" didn't expose api for the styling you wanted to do, your hands would be tied.

webdev is incredibly flexible by the very nature of "build it yourself", and that's a good thing.

Having performance impact from badly optimized implementation is a testament to this flexibility - what you are saying is akin to "C is bad because i could fk up memory"

Re: Don't attach tooltips to document.body

#77

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.

> Why is there no way to show tooltips immediately rather than having to wait a few seconds.

Because you don’t want tooltips to constantly flicker up when moving your mouse around. This should be a user preference setting, like e.g. double-click speed. (It is on Windows for native tooltips, via the registry.)

Re: Don't attach tooltips to document.body

#78
post #59
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 o…

That's why using a framework like angular it's a bad decision (besides many more reasons)

Re: Don't attach tooltips to document.body

#79
post #59
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 o…

Someday soon, someone will port WebKit to WASM, WebGL, etc.

Run your virtualized browser within any browser.

Re: Don't attach tooltips to document.body

#80

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…

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!

Post reply on HN