suggestion: refactor `canvas` features

[petele]

There are a handful of canvas features that are already done (canvas-context-lost, canvas-createconicalgradient, canvas-reset, etc). All of these include both the general Canvas 2D context, and the Offscreen Canvas context.

I suggest we refactor these into two features, canvas-2d, and canvas-offscreen, then include all the APIs for that context in a single web feature. Similarly, we'd also have canvas-webgl, canvas-webgl2, and canvas-webgpu.

Any objections or feedback before I proceed?

[foolip]

I agree we should have features for each kind of context. We already have offscreen-canvas, and we should also add:

• canvas-2d for canvas.getContext("2d")
• webgl for canvas.getContext("webgl")
• webgl2 for canvas.getContext("webgl2")
• webgpu for the whole WebGPU API, including canvas.getContext("webgpu")
• Maybe a feature for canvas.getContext("bitmaprenderer")?

I'm suggesting no canvas- prefix for most of them in line with https://github.com/web-platform-dx/web-features/tree/main/docs#names ("Prefer names known to be in widespread use by web developers") and https://github.com/web-platform-dx/web-features/tree/main/docs#identifiers ("Prefer shorter identifiers to longer identifiers, by avoiding common qualifiers and repeated words").

One thing I'm not sure about is whether we should have a feature for the <canvas> element itself and describe that it can be used with a number of different contexts, or roll it into Canvas 2D as https://caniuse.com/canvas does. I lean towards having it as a separate feature in https://github.com/web-platform-dx/web-features/pull/1365.

Then there's the question of the existing smaller canvas features, like Canvas reset(). These follow a common pattern of platform evolution:

• Interface X is introduced with a bunch of methods
• A similar interface Y is introduced with much of the same
• Going forward, new things are typically added to both X and Y

The challenge here is that when a new things like reset() is first shipped, it makes sense to talk about as one new feature. But as time passes, that single feature should probably be absorbed into two other features. We have never handled this situation yet. Most of https://webstatus.dev/?q=canvas is still newly available so I think keeping them separate is OK. But eventually we should consider deleting the features with a kind of tombstone that say "this feature was merged into Canvas 2D and Offscreen canvas".

Hope that helps! I would suggest starting by adding the new contexts to get lots and lots of BCD keys out of the way. It'll be easier to understand the remainder after that.

[petele]

Starting the work for the 2d context in #1500.

I'm suggesting no canvas- prefix for most of them

I think it's more clear when we do add it and adds some future proofing. For example, WebGPU may in the future have APIs for AI and APIs for drawing, and keeping those separate creates a clear differentiation. I also think it'll help for the smaller features issue mentioned below.

One thing I'm not sure about is whether we should have a feature for the <canvas> element

I agree separate is better.

Then there's the question of the existing smaller canvas features

After just giving a quick start on #1500, I think we're going to have to have separate entries for a significant number of these. But that potentially will lead to a large number of individual features/files, and some complexity on the file name. For example, transform is in Chrome 1, setTransform is in Cr2, resetTransform is in Cr31, and getTransform is in Cr68. They landed in very different versions, and I'd name the files canvas-2d-gettransform.yml etc.