|
> Oof - the point of WebAssembly is not to stick your entire UI in Canvas. Well, the way your operating system works with UI is that it gives each application one or more pixelbuffers, where the apps draw their pixels however they want (2D drawing API, 3D gpu-accelerated API, a widget toolkit, a HTML DOM renderer, etc). At the end of the day, you could say that any application interface is just a metaphorical Canvas - a memory buffer that is composited with other apps and eventually copied over to the screen buffer by the OS. Web browsers are becoming more and more like operating systems in this regard. Is it a good thing? That would be a good discussion. > This really rubs me the wrong way, it's a major step backwards for accessibility and user control. Accessibility has really nothing to do with Canvas, when you look at it simply as the API for drawing pixels. Accessibility is a way of providing the OS (or in this case the Browser, which in turn provides this info to the OS) with a parallel stream of information that describes the scene (text content, navigation controls, etc.) The OS then makes this info available to accessibility tools such as screen readers or data scrapers. Accessibility is a completely orthogonal concept and should not be tied to rendering. For example, you are probably not going to need to support a Braille screen reader in a 3D zombie shooter game, yet you can use Canvas 3D to render it. After all, accessibility in games is a different topic entirely. What you want, is an accessibility API that you can use or ignore, depending on your use case. If you don't want to deal with an accessibility API manually, use a widget toolkit that does it for you. Coincidentally, the Qt Widgets library has accessibility features implemented when the underlying platform provides an accessibility API. > Sometimes APIs on the web are difficult because they're poorly designed. I agree that most of the issues described in the parent post is a direct consequence of bad or non-existent API. After all, a runtime is nothing without powerful APIs. > I am increasingly suspecting that native developers just don't understand what the web is trying to do. The web is different from native because it's solving problems that native developers don't even realize they have. In all honesty, I believe if web developers took some lessons from the native world, they would realize that many of the problems of the web platform arise from its poor design and application of wrong paradigms on the wrong problems. Take the whole web UI thing for example. Even most trivial things, like trying to center something on the screen in HTML+CSS is a horrendously difficult chore with many possible and no right way of doing it. The whole idea, that a simple markup language that was designed for publishing and linking of text documents, can be used as the basis of a general-purpose application platform, is ridiculous. |
This is what I mean when I question whether native developers understand the web.
Accessibility has everything to do with semantic HTML. You're complaining that the browser doesn't give you an accessibility API. It does, it's called HTML. You're also allowed to separately style it, that's called CSS.
Heck, you don't even have to use it for your visuals. Qt could spit out a separate transparent HTML stream that never gets shown to users and that alone would help with a huge portion of the problems I listed above.
Or, much better, Qt could then apply styles to that separate stream of content and fall back to canvas only when CSS wasn't powerful enough to style a given widget, because accessibility is also about giving users access to that raw content so that they can override the look and feel of your application.
Of course, there are rare exceptions to this rule - for example, 3D games. They may use canvas and may not even expose an accessible view of the canvas contents (although to be clear, they could still do so via additional elements on the DOM). Again, this is the exception.
If an app is using Qt Widgets, of course they should be leveraging the browser's built in accessibility API, otherwise known as HTML.
> Even most trivial things, like trying to center something on the screen in HTML+CSS is a horrendously difficult chore with many possible and no right way of doing it.
What? Give your element a width and then set margin left/right to auto. If you want to do something very complicated, use flexbox or CSS grid. If all else fails and you're OK with using Javascript/WebAssembly (which Qt is) then you can even do polling and absolute positioning. CSS has plenty of dumb API decisions, but do people still actually struggle with centering elements?
This is the other thing that makes me suspect that native developers sometimes don't really understand what they're criticizing. It kind drives me crazy when native developers complain about stuff like this, given that the majority of the apps on my Linux box don't support fractional scaling for HDPI displays, can't handle multitouch, aren't built to use em units for margins and width when I customize my font size, and don't have any breakpoints for when they're resized or snapped to the side of a screen.
These are problems that we solved on the web over a decade ago. On native Linux platforms, we're still debating whether fractional scaling should happen within an app, or whether the window manager should handle it.
Some of CSS's complexity is there for good reason, because the extra tools and interactions are necessarily to style content in a way that works well with a platform as broad and diverse as the web. Some. That's a very qualified 'some', CSS does admittedly have some really dumb decisions in it.
But in general, I find it difficult to believe that native APIs have solved all of these problems, because otherwise I wouldn't want to swear every time I booted into Linux on a tablet.
> Web browsers are becoming more and more like operating systems in this regard. Is it a good thing?
It's a bad thing. We went through this with Flash and Java already. It wasn't just bad because of security vulnerabilities, it was also bad because people built their entire websites in Flash and Java and they were unresponsive, inaccessible, and broke common web paradigms like browser navigation and URLs.
What Qt is doing now is better in the sense that at least the code is now properly sandboxed, but it still falls into all of the other Flash and Java traps.