I got called out by a few of the maintainers back when Qt first started targeting WASM for criticizing their reliance on rendering binary blobs of pixels to a canvas instead of writing native components in HTML.
At the time, I was told that this was basically just a tech demo, and accessibility was actually the browsers' fault because there wasn't a Javascript API, and that all of the touch controls were going to be fine, and implementing all of the browsers' input methods by themselves was actually better than messing with CSS, and everything would be fine if I was patient.
So now, checking in, I can see that scrolling still doesn't work on my Mac, that the demos still aren't responsive and completely ignore the window width, that I still don't have any accessibility options, that keyboard shortcuts like `tab` still don't work, that text still isn't selectable or searchable, and that right-click is still broken.
For the cluster example[0] I'm downloading 30 MB! of code to render just three gauge charts on a page that uses 14MB of RAM. CPU fans immediately spin up -- I'm plugged in, but I can only imagine what this demo would do to my battery life.
I'm very excited about WASM, and there are some communities doing some really exciting things you should check out. Rust is well on its way to being a first-class language on the web. .NET had some really interesting demos. .NET actually renders your components as HTML, so there's potential you could use C#/.NET for practical web development, and not just for a quick port of an existing app. There are people doing cool things here.
But I don't think Qt is built for the web. The devs are trying to cram a square peg into a round hole, and I'm skeptical that their future efforts will be any better. My understanding is that even on native platforms, Qt does a lot of behind-the-scenes rendering computations that then gets painted out as a pixel array. If that's true, that could explain their insistence on doing the same thing here, but... that doesn't make it any better.
Don't use a WASM compiler that spits its entire interface into a canvas as a pixel array. I've seen a few people call this Flash 2.0, and honestly I think that's doing a disservice to Flash. Flash had better accessibility controls than this.
[0]: http://qt-webassembly.io/designviewer/#ClusterTutorial.qmlrc
Accessiblity will not work as emscripten does not have access to the DOM at this time. Emscripten is the magic here, not anything Qt is doing.
Regarding the issues you see: They ignore the browser width (and your other "issues") because they were designed that way. Check out: https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/qtb...
from https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/ind...
Seems responsive to me, tab works fine and dandy, text is selectable, right click works fine as well. I dunno what you are complaining about.
Other Qt WebAssembly apps behave like you want them to.
Rust has had this figured out for a while. You build a few helper methods in Javascript and call them from WASM.[0]
WASM has access to Javascript, so it has access to everything in the browser; that's already how Qt is getting the mouse position and intercepting keyboard events. Spitting pixels onto a canvas is an architecture decision, not a language restriction -- it's possible to build accessible WASM apps.
> Seems responsive to me, tab works fine and dandy, text is selectable, right click works fine as well. I dunno what you are complaining about.
From a quick test in Chromium:
- Right click won't work on mobile (long presses should trigger a right-click).
- Clicking on the main document to enter edit mode is broken via touch controls. You literally can't enter edit mode at all.
- Tab support is poorly implemented. On the web, when we talk about tab support, what we mean is that you should be able to use the entire interface from the keyboard. Here if you open a menu you'll immediately get stuck in an infinite loop. This is something you'd get for free if the menu was rendered with a
- element.
- Scrolling is inverted from my browser settings.
- Middle-click scrolling doesn't work at all.
- Searching for text doesn't work at all.
- On mobile interfaces or when looking at the app in responsive design mode, the entire interface gets scaled by a fixed percentage. This is particularly interesting, because that had to be a conscious choice. Container sizing just works on the web, I would need to think about how to break something like that.
- I don't know if the intention was to support all of the keyboard shortcuts the app lists (ctrl-f/command-f), but a lot of them don't work. I'm impressed that command-z gets correctly interpreted as undo. I guess the app must just check the user string to determine what OS I'm working on. I'm curious whether that'll also work on less common operating systems.
- Accessibility is obviously nonexistent, but the position of multiple Qt developers I've talked to is that this is apparently the browser's fault, not theirs. Still worth bringing up though, none of these apps are ever going to be compliant with A11y standards.
I'm leaving out any of the bugs I'm noticing with collision detection or resize performance, and just pointing out the issues that would be immediately fixed, for free, by rendering to HTML.
Also as a quick sidenote, stuff like broken scrolling isn't an "issue" in quotation marks. It's just a bug. I don't think you can chock something up like "my mouse scroll wheel should work" to a user preference. In the same way, you can blame accessibility problems on whoever you'd like, but a text editor that's impossible for a blind person to use is a real issue.