Re: [w3ctag/design-reviews] Canvas 2D color management (#646)

> > Following alpha's pattern, it's query-able using getContextAttributes (it will be in the returned CanvasRenderingContext2DSettings).
> > When creating a context, the color space for the context is set to the color space in the attributes, so all enum values that get past the IDL must be supported for 2D canvas and for ImageData. (Also, the proposal document advertised a feature detection interface, which was nixed in WhatWG review).
> 
> Just noticed this -- so if I'm reading this right the colorSpace from the attributes will be `srgb` in that case?

Sorry, I might not have understood the context of the question (let me know if I miss it again here!). WRT the question of "in unsupported color spaces will this attribute be `"srgb"`? There can be two meanings of "unsupported":
* A string that isn't a valid `PredefinedColorSpace`. This will throw an invalid enum exception.
* A string that is a valid `PredefinedColorSpace`, but isn't supported by the implementation. The intent of the language of the spec is for this category to not exist (e.g, there is no "supported versus not" in the [context creation algorithm](https://html.spec.whatwg.org/multipage/canvas.html#2d-context-creation-algorithm)). In some earlier versions of the WhatWG PR, there was this category of "a valid but not supported color space that falls back to sRGB", but this was considered too complicated (see discussion [here](https://github.com/whatwg/html/pull/6562#discussion_r611903604) for more details).

There's also the case of a user agent that hasn't implemented this feature. In that case, there will be no `colorSpace` entry in `CanvasRenderingContext2DSettings`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/646#issuecomment-865243237