Chrome, re: Color on the Web TPAC

Hey Group,

I sat in on this meeting
<https://www.w3.org/2019/09/17-colorweb-minutes.html> and committed to get
some answers from Chrome color folks.

Apologies for the delay! I made the mistake of starting an internal thread
with the intention of writing a summary to the color group. But that thread
got crazy long with internal details and tangents and its very difficult to
distill. I'll instead give simple incomplete answers and I expect
my @google colleagues to fill in the gaps and answer follow ups :). Next
time I'll just start the thread here...


*1. How do we feel about controlling HDR at element level vs the page
level? Folks made the point that it seems desirable to do element level to
enable mixing content, but Apple compositing dev was worried this would be
difficult for implementers.*

We generally support doing this at the element level. There are plenty of
challenges with both approaches. Per-element seems the most conceptually
clean. For ex, if you specify that the page is HDR, what does it then mean
when you load a non-HDR image? Pages cannot avoid this - they may not have
total control over the content they load or what context (top frame vs
iframe) they were loaded in.

Pages need some way to know when HDR is supported (and perhaps when/if that
changes dynamically). On that note, see CSS discussion here:
https://github.com/w3c/csswg-drafts/issues/4471

* 2. As a UA, what is our level of interest in HDR color throughout the
stack? Are we only interested in video? canvas? gl? or do we support hdr in
all the things (including css)? The underlying concern: they want to avoid
spec'ing something that never gets implemented.*

We're interested in HDR throughout the DOM. Obviously video HDR is here.
Image HDR seems near term. A simple WebGL/Canvas color space proposal has
been made (implemented in chrome behind flag). And we're watching the CSS
color spec.

There is some concern (ccameron@) about aspects of the CSS color 4 spec
(largely about complexity). I expect he'll have some bugs/ emails on that
shortly.


*We also discussed "working color space" intermixed with discussion of
SDR/HDR blending. Some agreement, but some open issues. *

I'll just drop some interesting key quotes...

   - "Extended-sRGB is the best working color space for compatibility
   reasons. Of note is that Chrome and Safari defy the spec (and will continue
   to do so) for power reasons (compositing in sRGB would massively-increase
   power consumption).
   I think that having a "switch the working color space for the page" flag
   is going to be very painful, and I don't see what it gets us."
   - "Working color space is essentially an implementation detail as long
   as it is specified how blending and compositing works."
   - "indeed, I've been using "working color space" and "color space for
   blending operations" interchangeably (which may be confusing some!)."
   - "Some of the [CSS] ideas (like working in perceptual spaces instead of
   RGB) seem great..."
   - "if we use wide intermediate spaces and then leave it to the OS to
   figure out how to best output that, we're giving it a very hard to solve
   problem, throwing away some information in doing so, and we'll see wildly
   different output by platform"


Best,
Chris