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.
Don't attach tooltips to document.body
71–80 of 98 posts
Re: Don't attach tooltips to document.body
#72... 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
#73Earlier 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 ?
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
#74It'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... 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.
Re: Don't attach tooltips to document.body
#76... 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.
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
#77It 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.
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... 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…
Re: Don't attach tooltips to document.body
#79... 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…
Run your virtualized browser within any browser.
Re: Don't attach tooltips to document.body
#80At 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…
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!