6 ms·

What’s wrong with using a single canvas? It can be faster. Google Docs and Figma, for example, use canvas rendering

slibhb 4y ago
I just checked and Google Docs is not a single canvas. It uses a canvas for the text but all the tools and so on are good old html.
- mhoad 4y ago
  Believe it’s a work in progress https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html?m=1 https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
dmitriid 4y ago
> What’s wrong with using a single canvas You can't even select and copy text. And canvas is inaccessible to screen readers
- the_duke 4y ago
  For accessibility they create a separate DOM tree just for screen readers.
  - steve_adams_86 4y ago
    Are there declarative and performant ways to synchronize a canvas with a DOM tree? Maybe the answer here is obvious but this seems like quite a bit of overhead, both for developers and the browser.
    - SemanticStrengh 4y ago
      at this point you'd better get rid of the canvas
    - 10000truths 4y ago
      Do they need to be synchronized? I can’t imagine that a screen reader would be sensitive to millisecond-level discrepancies between canvas updates and DOM updates.
      - steve_adams_86 4y ago
        I’m not concerned about the delay between updates, it’s the correctness of the DOM and the canvas and managing interactions between the two. I might be misunderstanding the problem (or lack thereof) because I haven’t dealt with accessibility and canvas. When it comes down to it, I have no idea how you’d indicate something is selected in the canvas and have a screen reader correctly read out the current selection from the DOM. Would DOM events communicate to the canvas how to modify state, functions to call, etc? How would you manage focus between the canvas element and the rest of the DOM? Apologies if I’m not making sense; maybe there’s a well known pattern people use for things like this. My understanding of accessibility relies heavily on the DOM behaving as a single document, and the idea of a sort of meta-document within it which coordinates pieces of the documents seems very complex and hard to get right.
  - LocalPCGuy 4y ago
    This right here should tell you why you shouldn't use Flutter for Web. The Web is pretty great for accessibility out of the box until us devs mess it up, we shouldn't use a technology that needs to completely build it from scratch to get it to work.
    - mhoad 4y ago
      Just as an FYI that is how the official web spec works https://wicg.github.io/aom/spec/ https://wicg.github.io/aom/spec/ I'm going off of memory here but I think it's approximately correct. They were playing around with the idea for a while of creating "virtual trees" to handle accessibility and ultimately had to abandon it for privacy reasons because you would be able to imply that anyone who was using the virtual tree was differently abled and that was a whole can of worms that couldn't be resolved.
      - LocalPCGuy 4y ago
        I believe the spec you link is a future proposal at the moment. And I trust a consortium of folks from a variety of browser vendors along with folks from other interests over a single product, when it comes to trying to figure out a better way to make things more accessible. And maybe Flutter can just use AOM in the future when it's available in browsers. As of Feb, 2022: > While still in draft form within the Web Incubator Community Group, the Accessibility Object Model (AOM) intends to incubate APIs that make it easier to express accessibility semantics and potentially allow read access to the computed accessibility tree.
- wildrhythms 4y ago
  FYI there is a SelectableText widget included in Flutter[1] but the developer has to explicitly make text selectable just like iOS and just like Android apps. Desktop is a different story... many text selection paradigms that I'm familiar with on desktop (like double-click and hold and drag to select whole words) simply don't work right. It's not a great experience, but neither is the vast majority of non-Flutter mobile apps when it comes to selecting text too. wrt accessibility, Flutter does actually generate elements with aria attributes for screenreaders to consume[2]. You're right that the canvas is inaccessible, which is why the aria labels have to be generated adjacent to that. We're using Flutter for mobile development at my workplace. [1] https://api.flutter.dev/flutter/material/SelectableText-class.html https://api.flutter.dev/flutter/material/SelectableText-clas... [2] https://docs.flutter.dev/development/accessibility-and-localization/accessibility https://docs.flutter.dev/development/accessibility-and-local...
kolanos 4y ago
Both are pretty disastrous accessibility-wise.
SemanticStrengh 4y ago
no canvas are slower for UIs. The difference is between immediate vs retained mode rendering, and the later is order of magnitude more energy efficiency and is more performant, for well behaving not chaotically changing content.
gitgud 4y ago
Although it may render faster, it comes at a cost, as it completely circumvents what browsers are good at. Flutter is basically just painting pixels on a canvas manually, meaning no CSS, no text selection, no text wrapping, no responsive elements, no elements without JS enabled. Many accessibility tools rely on CSS and text in HTML in order to work too. It's a huge trade-off to make, and something to be aware of.
- LocalPCGuy 4y ago
  Heavy emphasis on HUGE tradeoff. Too much for most web apps, IMO.
strix_varius 4y ago
Both Google docs and figma use canvases, but neither of them renders the whole app through a canvas. This is easy to verify - just open up dev tools and look at the DOM structure.
busymom0 4y ago
Canvas has accessibility issues for screen readers as well as for SEO purposes.
kevincox 4y ago
Because it destorys native browser features. For example find-in-page, hove to see where a link goes. Right click a link to bookmark, open in private window or copy the URL. If the page has anchors I can get a link to them. If I save or print the page it is an image rather than text (with all of the above features). Some of these can be reimplemented easily, some of them with effort, but some just aren't possible. Plus the exact behaviours depend on what browser you are using, so you can't reimplement them because you don't know how the user's browser behaves. For games or image editors this is probably fine. But for most apps this is a huge depredation in usability.

I just checked and Google Docs is not a single canvas. It uses a canvas for the text but all the tools and so on are good old html.

mhoad 4y ago
Believe it’s a work in progress https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html?m=1 https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...

dmitriid 4y ago

> What’s wrong with using a single canvas You can't even select and copy text. And canvas is inaccessible to screen readers

the_duke 4y ago
For accessibility they create a separate DOM tree just for screen readers.
- steve_adams_86 4y ago
  Are there declarative and performant ways to synchronize a canvas with a DOM tree? Maybe the answer here is obvious but this seems like quite a bit of overhead, both for developers and the browser.
  - SemanticStrengh 4y ago
    at this point you'd better get rid of the canvas
  - 10000truths 4y ago
    Do they need to be synchronized? I can’t imagine that a screen reader would be sensitive to millisecond-level discrepancies between canvas updates and DOM updates.
    - steve_adams_86 4y ago
      I’m not concerned about the delay between updates, it’s the correctness of the DOM and the canvas and managing interactions between the two. I might be misunderstanding the problem (or lack thereof) because I haven’t dealt with accessibility and canvas. When it comes down to it, I have no idea how you’d indicate something is selected in the canvas and have a screen reader correctly read out the current selection from the DOM. Would DOM events communicate to the canvas how to modify state, functions to call, etc? How would you manage focus between the canvas element and the rest of the DOM? Apologies if I’m not making sense; maybe there’s a well known pattern people use for things like this. My understanding of accessibility relies heavily on the DOM behaving as a single document, and the idea of a sort of meta-document within it which coordinates pieces of the documents seems very complex and hard to get right.
- LocalPCGuy 4y ago
  This right here should tell you why you shouldn't use Flutter for Web. The Web is pretty great for accessibility out of the box until us devs mess it up, we shouldn't use a technology that needs to completely build it from scratch to get it to work.
  - mhoad 4y ago
    Just as an FYI that is how the official web spec works https://wicg.github.io/aom/spec/ https://wicg.github.io/aom/spec/ I'm going off of memory here but I think it's approximately correct. They were playing around with the idea for a while of creating "virtual trees" to handle accessibility and ultimately had to abandon it for privacy reasons because you would be able to imply that anyone who was using the virtual tree was differently abled and that was a whole can of worms that couldn't be resolved.
    - LocalPCGuy 4y ago
      I believe the spec you link is a future proposal at the moment. And I trust a consortium of folks from a variety of browser vendors along with folks from other interests over a single product, when it comes to trying to figure out a better way to make things more accessible. And maybe Flutter can just use AOM in the future when it's available in browsers. As of Feb, 2022: > While still in draft form within the Web Incubator Community Group, the Accessibility Object Model (AOM) intends to incubate APIs that make it easier to express accessibility semantics and potentially allow read access to the computed accessibility tree.
wildrhythms 4y ago
FYI there is a SelectableText widget included in Flutter[1] but the developer has to explicitly make text selectable just like iOS and just like Android apps. Desktop is a different story... many text selection paradigms that I'm familiar with on desktop (like double-click and hold and drag to select whole words) simply don't work right. It's not a great experience, but neither is the vast majority of non-Flutter mobile apps when it comes to selecting text too. wrt accessibility, Flutter does actually generate elements with aria attributes for screenreaders to consume[2]. You're right that the canvas is inaccessible, which is why the aria labels have to be generated adjacent to that. We're using Flutter for mobile development at my workplace. [1] https://api.flutter.dev/flutter/material/SelectableText-class.html https://api.flutter.dev/flutter/material/SelectableText-clas... [2] https://docs.flutter.dev/development/accessibility-and-localization/accessibility https://docs.flutter.dev/development/accessibility-and-local...

kolanos 4y ago

Both are pretty disastrous accessibility-wise.

SemanticStrengh 4y ago

no canvas are slower for UIs. The difference is between immediate vs retained mode rendering, and the later is order of magnitude more energy efficiency and is more performant, for well behaving not chaotically changing content.

gitgud 4y ago

Although it may render faster, it comes at a cost, as it completely circumvents what browsers are good at. Flutter is basically just painting pixels on a canvas manually, meaning no CSS, no text selection, no text wrapping, no responsive elements, no elements without JS enabled. Many accessibility tools rely on CSS and text in HTML in order to work too. It's a huge trade-off to make, and something to be aware of.

LocalPCGuy 4y ago
Heavy emphasis on HUGE tradeoff. Too much for most web apps, IMO.

strix_varius 4y ago

Both Google docs and figma use canvases, but neither of them renders the whole app through a canvas. This is easy to verify - just open up dev tools and look at the DOM structure.

busymom0 4y ago

Canvas has accessibility issues for screen readers as well as for SEO purposes.

kevincox 4y ago

Because it destorys native browser features. For example find-in-page, hove to see where a link goes. Right click a link to bookmark, open in private window or copy the URL. If the page has anchors I can get a link to them. If I save or print the page it is an image rather than text (with all of the above features). Some of these can be reimplemented easily, some of them with effort, but some just aren't possible. Plus the exact behaviours depend on what browser you are using, so you can't reimplement them because you don't know how the user's browser behaves. For games or image editors this is probably fine. But for most apps this is a huge depredation in usability.