w3ctag / design-principles

A small-but-growing set of design principles collected by the TAG while reviewing specifications
https://w3ctag.github.io/design-principles
160 stars 44 forks source link

What should be the principles be about appropriate use cases for the canvas element? #369

Open chrishtr opened 2 years ago

chrishtr commented 2 years ago

HTML is the way information and UI is generally represented on the web. This declarative format has all of the advantages that we know about: admits user agent features, responsive design, accessibility, search engine indexing etc.

HTML also has a <canvas> element, which is used for a wide variety of use cases, such as charts and visuals, games, and interactive ads. Some desktop publishing sites such as Google Docs and Sheets also use canvas for the rendering of the main content area, with HTML for the surrounding menus and other UI elements.

From time to time there are proposals to render entire application UIs in canvas, skipping HTML. A common motivation is cross-platform (web and native app in one code base) or cross-browser (fewer interoperability concerns across browsers) "write once" apps. This approach may achieve those goals, but as a consequence, many of the advantages of HTML I mentioned above are by default lost.

It seems appropriate to have design principles for the web about the right way to think about canvas vs HTML, and what use cases are a good match for each, while taking into account the priority of constituencies. These principles can help us inform where to focus our new API work. For example, what should the best practices be for expressing accessibility for content in <canvas>?

cynthia commented 2 years ago

I think the issue here is that we don't particularly offer authoring advice as part of the principles, and this seems like it would fall into the bucket of authoring guidance.

Unless we are misunderstanding, and there a specific API proposal you have in mind. (where you have observed an antipattern)

chrisn commented 2 years ago

In the TV app space, we're seeing an emerging trend towards use of canvas for UI rendering, to avoid performance issues with HTML and CSS based rendering on devices with limited CPU and memory resources.

Best practice guidance would be welcome (here, or elsewhere if not in scope), also exploration of the need for API support for accessibility.

chrishtr commented 2 years ago

Unless we are misunderstanding, and there a specific API proposal you have in mind. (where you have observed an antipattern)

There is no particular API I have in mind. But I do think it makes sense for the TAG to take a position on questions such as "would it be appropriate to add sufficient APIs to canvas that applications need not be written in HTML?", e.g. by adding in API substitutes for many or all of typical user agent features, such as find-in-page, selection, translation, spellcheck, and viewing text content, as well as rendering APIs such as layout and styling.

torgo commented 1 year ago

We discussed today how this might fit into a wider "design principles for web developers" doc that we might work on.