[css-mediaqueries] Clarify propagated preferred color-scheme on SVG images with color-scheme: normal and no color-scheme meta tag

[emilio]

In #7213 we resolved for the preferred color-scheme for SVG images to be context dependent.

However what "context dependent" means can be a bit fuzzy. The way I implemented it in Firefox is using the used color-scheme.

That's usually fine, but for pages which don't use the color-scheme property or meta-tag it is a subtle behavior change, because all the SVG images become light (rather than the previous behavior, which is using the OS preferred color-scheme).

@progers mentioned that they have data that indicates that usage of the prefers-color-scheme media query is much higher than the color-scheme property / meta tag, and we've seen one case of breakage already: https://bugzilla.mozilla.org/show_bug.cgi?id=1779874

I think it'd be better to deal with this case a bit more subtly. Proposed behavior:

• If there's a non-normal color-scheme property or meta tag, then use that color-scheme to propagate to SVG images.
• Otherwise use the preferred color-scheme of the document (whatever prefers-color-scheme matches), rather than the "used color scheme" which would be light.

I think this makes sense because we're propagating a preference, rather than the used-color-scheme (so propagating the parent page preference for the normal case makes sense). For our internal use cases in Firefox it didn't quite matter because all internal pages support both light and dark mode.

I think this would be similarly-sensible behavior, and a bit more backwards-compatible. It means that we need to provide that extra definition ("effective color-scheme preference" or something?) on the spec.

Thoughts? cc @lilles @progers @smfr @tabatkins

[progers]

This area is complex and I would like to avoid adding special-cases to the svg embedding case. It would be ideal if we could resolve the differences between svg and iframe embedding too.

For backwards compatibility (e.g., pages would become unreadable with a black background), we cannot let color-scheme default to the preferred color scheme, so maybe it is best to disentangle the prefers-color-scheme media query and color-scheme? For example, color-scheme could just control browser UX (described here), and prefers-color-scheme could just return the OS dark mode setting or other user-set value. In this model, there are no differences between content in iframes vs svg. Embedded svg content with prefers-color-scheme media queries would match the global setting.

[css-meeting-bot]

The CSS Working Group just discussed Propagated preferred-color-scheme on SVG images, and agreed to the following:

• RESOLVED: do what Emilio said
• RESOLVED: for the purposes of propagating prefers-color-scheme to the embedded page, if `color-scheme` is `normal` and there's no `color-scheme` meta tag, the propagated scheme is the preferred color-scheme of the embedder document

The full IRC log of that discussion

<fantasai> Subtopic: Propagated preferred-color-scheme on SVG images
<pdr> https://github.com//issues/7526
<astearns> github: https://github.com//issues/7526
<fantasai> emilio: Previous issue, we resolved that preferred-color-scheme on SVG images was going to depend of the color scheme of the embedder element
<fantasai> emilio: what we didn't define is what happened when color-scheme: normal and color scheme is unannotated
<fantasai> emilio: this changes behavior, because used color scheme defaults to light
<fantasai> emilio: no color scheme meta, and color-scheme: normal, used color scheme is light
<fantasai> emilio: so pages that don't annotate it, get light instead of dark
<fantasai> emilio: I think we need another concept that preserves the preferred color scheme of the embedding document
<fantasai> emilio: I think it's a relatively straightforward fix
<fantasai> emilio: Philip prefers not to change the behavior
<fantasai> emilio: I think it's nice that the color scheme would depend on ?
<fantasai> emilio: same for iframes
<fantasai> emilio: I agree that having special cases for SVG, I think we should behave the same way for iframes
<fantasai> TabAtkins: Assuming not security blocked, yes
<fantasai> emilio: So my proposal is splitting used color scheme from preferred color scheme
<fantasai> emilio: propagated preferred color scheme or osmething
<fantasai> emilio: so the default when unannotated isn't light, it's the embedder's color scheme
<pdr> q+
<astearns> ack pdr
<fantasai> pdr: I think it would be useful to step back and consider ?? and ??? atwo differen things
<fantasai> pdr: color-scheme tells the browser how the author wants, and prefers-color-scheme tells us what the OS wants
<emilio> color-scheme and prefers-color-scheme
<fantasai> pdr: the behavior here is clear, the embedder is asking for color scheme
<fantasai> pdr: combine them, gets complicated
<astearns> s/?? and ???/color-scheme and prefers-color-scheme/
<fantasai> pdr: reason is, you can't make color-scheme follow prefers-color-scheme by default
<fantasai> pdr: some websites are designed to have light scrollbars, flip it to dark, it's ugly
<fantasai> pdr: we can't really ignore concepts are tightly intertwined
<fantasai> pdr: given all the issues with SVG and iframe, adds ocmplexity that's not necessary
<emilio> q+
<fantasai> pdr: just have color-scheme be the browser's color scheme and prefers-color-scheme be the OS
<astearns> ack emilio
<TabAtkins> q+
<fantasai> emilio: The reason why I think prefers-color-scheme follow the embedder, otherwise it's useless in embedder and in iframe
<fantasai> emilio: it's not useful to know that OS prefers dark, because you don't care about OS being dark, you care about your context being dark
<fantasai> TabAtkins: yes
<fantasai> TabAtkins: if page said 'color-scheme: dark', SVG should be dark by default
<fantasai> TabAtkins: if they're light, this is a problem
<astearns> ack TabAtkins
<fantasai> TabAtkins: we want to fix this breaking case
<fantasai> emilio: regarding the point of complexity,
<fantasai> emilio: in Gecko you already need to have prefers-color-scheme as a key in the image tag
<fantasai> emilio: I think Blink has similar mechanism
<fantasai> emilio: in terms of complexity, in Gecko it's mostly a one-liner
<fantasai> emilio: I agree it can be difficult to wrap your head around it in the first place, but in terms of implementation complexity
<fantasai> emilio: it's simple to default to document rather than OS color scheme
<fantasai> pdr: If you have SVG content, and embedded, it looks different
<fantasai> TabAtkins: Assuming not cross-origin iframe or other security-conscious spot
<fantasai> TabAtkins: iframe should behave same as image
<fantasai> TabAtkins: should get color scheme passed through
<fantasai> TabAtkins: it's only in cases where we want to restrict cross-origin communication that we cut it off
<fantasai> TabAtkins: ....
<fantasai> TabAtkins: in other cases can exfiltrate, and could od something different
<fantasai> TabAtkins: but in all other cases, want to keep consistency between iframe and other ways of embedding SVGs
<fantasai> pdr: [missed]
<fantasai> TabAtkins: cross-origin iframes restrict in a number of ways
<fantasai> TabAtkins: and CSS doesn't pass much info, mainly width/height
<fantasai> TabAtkins: and we would like to minimize cross-origin info propagation
<dbaron> s/[missed]/is there precedent for developers dealing with situations where APIs work so differently in cross-origin iframes
<fantasai> TabAtkins: in fact we're doing more cross-origin restrictions with (new feature)
<fantasai> TabAtkins: because so restricted, I doubt very surprising for authors
<fantasai> pdr: There's SVGs in ads, and they're frequently mixed in cross-origin contexts
<fantasai> pdr: from user's perspective, will be difficult to tell
<fantasai> pdr: why not specify fully the iframe/
<fantasai> emilio: there's another issue on that
<fantasai> emilio: I talked to security folks about this, and the tldr is they didn't find anything particularly concerning to make it behave the same as SVG
<fantasai> emilio: It's basically depending on Chrome's security folks to take a look to make it behave consistently everywhere
<fantasai> emilio: use cases where exfiltration is a problem, ...
<fantasai> emilio: You can't tell if color-scheme is coming from OS or from page
<fantasai> emilio: if you're loaded in both cross-origin and original context...
<fantasai> emilio: doesn't seem that problematic
<fantasai> emilio: it's one bit that we stop passing from OS and start passing from the page
<fantasai> emilio: later in agenda
<fantasai> emilio: I'm for making all embedding contexts behave consistently in this regard
<fantasai> TabAtkins: I'm operating from idea that we want to lock down crossorigin communication
<fantasai> TabAtkins: but if one more bit is not considered a problem then ok
<fantasai> emilio: My point is that, we stop exposing one bit from OS and start exposing from one page
<bkardell_> q+
<fantasai> emilio: the only way for embedded page to differentiate is if it's also loaded in a different context (top-level or other)
<fantasai> TabAtkins: as long as we're locking down ?
<fantasai> TabAtkins: so long as there is zero ability to coordinate between parties
<fantasai> TabAtkins: then I don't care
<TabAtkins> s/?/cases liked fencedframe/
<bkardell_> q-
<astearns> ack bkardell_
<fremy> q+
<fantasai> astearns: Philip, have your concerns been addressed?
<fantasai> pdr: Would be happier if not a special case
<fremy> q-
<fantasai> pdr: Emilio's proposal is not overall bad
<fantasai> TabAtkins: proposal is we propagate used color scheme to all embedded contexts regardless?
<fantasai> emilio: This is about page with color-scheme: normal, no color scheme meta
<fantasai> emilio: instead of propagating used color scheme, we propagate preferred color scheme of the document
<fantasai> emilio: recursively
<fantasai> TabAtkins: that sounds good
<fantasai> dbaron: please summarize into IRC!
<fantasai> fremy: so idea is on the viewport, if you didn't specify color-scheme, you get the value that you get from the meta tag?
<TabAtkins> proposed resolution: when the embedding page doesn't set color-scheme (or sets it to 'normal'), we don't propagate used color-scheme to embedded pages (they continue to get the OS-derived preferences)
<fantasai> fremy: if you have a web page that does not specify any color scheme property, just using default, it will propagate to iframes the value that is used in the meta tag
<fantasai> emilio: yes, that's how used color scheme alread work
<fantasai> emilio: this case, if on top of that there's no meta, instead of propagating 'light', which is the default used color scheme, you propagate the preferred color scheme of the parent document
<fantasai> emilio: My thought is that instead of using OS preferrence, we use preference of embedding page
<fantasai> emilio: it's usualy OS color scheme, except when you have nested embedding
<fantasai> TabAtkins: Ah, so if top level sets color scheme, second level doesn't, third level gets the top-level scheme
<fantasai> emilio: exactly
<TabAtkins> proposal: if the embedding page doesn't set a color-scheme, it propagates the default color scheme to embedded pages (rather than passing its used color scheme)
<emilio> Proposed resolution: for the purposes of propagating prefers-color-scheme to the embedded page, if `color-scheme` is `normal` and there's no `color-scheme` meta tag, the propagated scheme is the preferred color-scheme of the embedder document
<TabAtkins> (this matters for A->B->C, where A sets 'color-scheme' but B doesn't. In this case, C will get A's used scheme, without B's lack of care (which'll resolve to 'light') affecting it)
<dholbert> TabAtkins: ("default"/"used" might be confusing/ambiguous in your wording)
<fremy> lgtm
<fantasai> fantasai: Sounds good to me, let's resolve
<fantasai> astearns: objections?
<fantasai> RESOLVED: do what Emilio said
<dbaron> RESOLVED: for the purposes of propagating prefers-color-scheme to the embedded page, if `color-scheme` is `normal` and there's no `color-scheme` meta tag, the propagated scheme is the preferred color-scheme of the embedder document