[HTML] Canvas place element

[khushalsagar]

こんにちは 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.

• Explainer¹: https://github.com/WICG/canvas-place-element/blob/main/README.md
• User research:
• Security and Privacy self-review²: https://github.com/WICG/canvas-place-element/blob/main/security-privacy-questionnaire.md
• GitHub repo: https://github.com/WICG/canvas-place-element
• Primary contacts:
  • Fernando (@fserb), Google, Spec author
  • Khushal (@khushalsagar), Google, Spec author
  • Stephen Chenney (@schenney), Igalia, Spec author
• Organization/project driving the design:
  • Google
  • Igalia
• Multi-stakeholder feedback³:
  • Chromium comments: Supportive, we have a prototype landing in Blink.
  • Mozilla comments: [HTML] Canvas place element mozilla/standards-positions#1076
  • WebKit comments: [HTML] Canvas place element WebKit/standards-positions#403
  • Developer feedback: https://docs.google.com/document/d/13M0VtYSAnl_aU7SQoFBuM2DrAkQTZSFHi_ojypJdcpA/edit

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

[matatk]

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.