#997: [HTML] Canvas place element

Visit on Github.

Opened Sep 25, 2024

こんにちは TAG-さん!

I'm requesting an early TAG design review of "Canvas place element".

A fundamental capability missing from the web is the ability to complement Canvas with HTML elements. Adding this capability enables Canvas surfaces to benefit from all of the styling, layout and behaviors of HTML, including interactive elements and built-in accessibility.

There are 2 API surfaces to be exposed on this proposal. First, a high level API that brings an Element and its subtree into the 2D Canvas. Second, a broken down version that allows finer control over Javascript and is also available in 3D contexts.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  • The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
  • Existing major pieces of multi-implementer review or discussion of this design:
  • Major unresolved issues with or opposition to this design:
  • This work is being funded by: Google

Discussions

Log in to see TAG-private discussions.

Discussed Oct 1, 2024 (See Github)

Matthew: This is really interesting. Could be pretty helpful. People use <canvas> to render a whole webapp. Instead of using HTML elements, they draw pixels, so it's not accessible, but they want exact control over appearance. Can put fallback elements inside the canvas. They don't get rendered, but they're available to AT. This allows you to put those elements on the canvas in a particular place. They say it's great because it'll be good for accessibility. That aspect does sound good. Concerned that use cases aren't explained well enough, because if you're using canvas to avoid native elements, why would you use this?

Jeffrey: We should ask them to explain the use cases, if they're not clear enough in the explainer. I'm pretty sure they'd have a partner who's interested in using this, but they might not have enough partners.

Matthew: It's sometimes not enough to show a particular element for example if the focus indicator actually lives on one of its ancestors. They said you could use this for a menu in a game. But if you're placing things at particular pixel locations, you're doing a lot of the layout yourself, and what if the user has changed the base font size? They talked about "and its children", so maybe you wouldn't place menu items. That should be made very clear to developers.

Jeffrey: Can we point them to a particular accessibility group?

Matthew: Point them to APA. We might point them toward the ARIA people. We have the TAG question about use cases, in addition to the accessibility question. I'll post a comment this evening.

Discussed Oct 1, 2024 (See Github)

we discuss and agree Matthew's comment

Tess: I think this has been tried before.... in ancient whatwg mailing list issues...

Matthew posted a comment, including a couple of edits suggested by Jeffrey

Comment by @matatk Oct 21, 2024 (See Github)

Thanks for all the info on this interesting proposal (we're happy to see you're using the WHATWG Stages process). You've listed several general advantages of placing elements on the canvas, but there isn't much info in the explainer (no specifics at the beginning) on the specific use cases you envisage for this. Please could you add those at the beginning of the explainer?

There are a few areas in which it would be wise to warn developers that they still need to do some additional work in order to ensure the accessibility of the controls, such as ensuring that focus indicators are visible against variable canvas 'background' content. Also, some people would find it hard to read text content that is significantly rotated, for example. Whilst cases like these are inherently covered by WCAG, it would be a good idea to remind developers that they need to check these things - something to consider for the developer docs in future.

How do you envisage that the user's varying base font size, zoom level, and/or viewport size would come into play? For example, when elements are placed at specific coordinates, there seems to be a risk that they could end up overlapping/occluding each other, or having content truncated, if the user increased the base font size, or zoomed the page.

We also encourage you to get in touch with the Accessible Platform Architectures (APA) WG, this group provides accessibility review and may have more input/suggestions (I'm one of the co-chairs). You can get in touch with APA by adding the a11y-tracker label to an issue in any W3C or WHATWG repo.