Thank you for the clarification, Justin.
Suppose I ask for “optimal” and get back a 10-10-10-2, rec2020 Canvases. What will the colorspace be set to? It shouldn’t be linear-rec2020 because the values are not linear and the bitness is not floating point.
I don’t think it is a good idea for the API to return colorspaces that are not in the spec, especially for the “optimal” request. This creates a big moving target for developers wanting to write content that works across as many devices as possible. Content will work great on devices the web developer happens to have access to but then falls apart in the wild. If you get back 10-10-10-2, then the Canvas may not even have full alpha blending. I think if we’re going to have “optimal” be a choice, then it should resolve to a known palette of choices.
Also, if we’re going to have rec2020 sometimes be a floating point texture and sometimes be 10/10/10/2, then there should be a way for the developer to figure out the bitness and gamma of what was chosen. This is important for WebGL where the developer has to arrange for the final colors to be in the right colorspace/gamma. Either we have additional strings the web developer needs to compare against or individual strings that give the bitness and gamma separate from the colorspace.
I recently ran your proposal by the DirectX team. One of the pieces of feedback they gave was the worry about having one string for all combinations of gamma, bitness and colorspace. For bitness, we have 8bpc, 16fbpc and 10-10-10-2. For colorspace, we have sRGB, AdobeRGB, DCI-P3, BT.2020 and others. For gamma we have ST.2084, linear gamma, HLG (hybrid-log gamma) and others “surely to come” according to them. That’s a lot of enums if we do all combinations. Now perhaps today, we keep it simple and support only a subset of combinations and see how things go. But this is something to keep in mind as we design for the future.