3 ms·

> And I’m just mentioning some of the unfixable problems with this approach I agree that using a canvas instead of leveraging existing accessibility supplied b

> And I’m just mentioning some of the unfixable problems with this approach I agree that using a canvas instead of leveraging existing accessibility supplied by HTML/CSS/JS and the DOM is an accessibility nightmare. However, I disagree that canvas accessibility issues are "unfixable". Difficult? Yes. But not unfixable. In my view, the <canvas> element works best in partnership with its wider environment (HTML/CSS/JS and the DOM), not as a replacement for it. With that in mind, we can start to tackle the accessibility issues you raise - fonts, links, interactions, etc.[1][2] I have an ambition to one day become intelligent enough to understand/code in Rust, and I'm really glad to see that people are thinking about accessibility as a fundamental part of UIs being developed in Rust. [1] - Which is what my JS 2d canvas library tries to do: https://scrawl-v8.rikweb.org.uk/ https://scrawl-v8.rikweb.org.uk/ [2] - My thoughts on <canvas> accessibility, and how I try to fix them using my library: https://scrawl-v8.rikweb.org.uk/learn/eleventh-lesson/ https://scrawl-v8.rikweb.org.uk/learn/eleventh-lesson/

chrismorgan 4y ago
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.)

chrismorgan 4y ago

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.)