I am specifically speaking of egui’s strongly canvas-only approach. It doesn’t want partnership with its wider environment, it wants to replace it. In that appr

I am specifically speaking of egui’s strongly canvas-only approach. It doesn’t want partnership with its wider environment, it wants to replace it. In that approach, these issues are fundamentally unfixable. I’ll focus on the two most obviously significant issues: ① Scrolling. The only complete solution is to draw within scrolling elements. To treat scrolling content distinctly, and allow the browser to act as the compositor. This would require rebuilding egui from the ground up; its current philosophy is just completely incompatible. ② Links. The only complete solution is to use actual link elements. My complaints about scrawl-canvas’s handling of links <https://news.ycombinator.com/item?id=22887235 https://news.ycombinator.com/item?id=22887235> when you submitted it here 2½ years ago still apply: to get it right, you’ve got to use actual links, placed in the right place, so that that’s what the cursor is actually interacting with the whole time. The difference here from scrolling is that they can be transparent elements on top of everything else. On reflection, I think it might be theoretically possible for AccessKit to achieve this itself in the simplest cases, but that would certainly break egui’s conception of how things should work, and it can’t work generally because of event handling, the possibility of a non-rectangular hit box, and the fact that egui is a compositor (you could have a window completely covering your link). And so I say: these are unfixable issues in egui’s design. (I also report strongly negative experiences with every canvas-plus-DOM approach I’ve encountered. They never get everything right, and the duplication required to get things as close to right as possible almost always leaves me wondering why you bothered with the canvas parts in the first place.)