[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent? #7213

emilio · 2022-04-13T15:43:08Z

Consider this test-case:

<!doctype html>
<div style="color-scheme: light">
  <img>
</div>
<div style="color-scheme: dark">
  <img>
</div>
<script>
  for (let img of document.querySelectorAll("img")) {
    img.src = "data:image/svg+xml;base64," + btoa(`
      <svg width="32" height="32" viewBox="0 0 32 32" xmlns="http://www.w3.org/2000/svg">
        <style>
          :root { color: blue }
          @media (prefers-color-scheme: dark) {
            :root { color: purple }
          }
        </style>
        <rect fill="currentColor" width="32" height="32"/>
      </svg>
    `);
  }
</script>

Right now the rendering of those images match in all browsers, but one could argue that perhaps they should render differently (top blue, bottom purple)?

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1764354, which is what prompted this discussion.

cc @lilles @smfr

emilio · 2022-04-13T18:19:10Z

cc #6988 which is somewhat related.

tabatkins · 2022-04-14T18:23:12Z

Yeah, so basically you're asking if the used color scheme should automatically inherit into nested documents. That's a communication bit, which we try to avoid adding for cross-origin stuff, at least.

(#6988 would allow passing the color-scheme in purposely, if both the outer and inner page successfully handshaked.)

emilio · 2022-04-14T19:02:57Z

Right. My reasoning for doing this for SVG images is that they cannot run script, etc, so it's a much more limited environment. But I guess you're right that they could trigger different image loads to exfiltrate that bit, potentially.

For the record, Gecko does inherit the color scheme into some frames (so that e.g., extension setting popups behave correctly if you have a dark Firefox theme but a light content theme). This is not exposed to regular <iframe>s on websites, though.

lilles · 2022-04-20T13:06:50Z

The comment: #7213 (comment) confused me a bit since @emilio's example affects the preferred color-scheme, not the used color-scheme or color-scheme property directly.

This is about changing the preferred color-scheme in the SVG and the SVG root color-scheme would not be affected in another way than through the preferred color-scheme, right?

emilio · 2022-04-20T16:05:18Z

Yeah, that's right.

css-meeting-bot · 2022-04-20T16:26:41Z

The CSS Working Group just discussed [css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent?, and agreed to the following:

RESOLVED: Have prefered-color-scheme reflect 'color-scheme' on the embedding element in the embedding document, to the extent acceptable from security standpoint (pending security review)

The full IRC log of that discussion

<fantasai> topic: [css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent?
<fantasai> github: https://github.com//issues/7213
<fantasai> emilio: We got an interesting bug report in Firefox
<fantasai> emilio: When you have a Firefox theme that's dark, but OS theme is light
<fantasai> emilio: sites can't choose a reasonable favicon for dark mode
<fantasai> emilio: Suggestion is to make preferred-color-scheme for SVG images reflect the used color scheme
<fantasai> emilio: Then could have light+dark icons anywhere in your page, and then as long as your parent has the correct color-scheme will display correctly
<fantasai> emilio: Maybe worth making this more general
<fantasai> emilio: Tab seemed to have some reservations
<fantasai> TabAtkins: This makes a cross-origin communication bit, and we try to restrict those
<fantasai> TabAtkins: use case makes sense
<fantasai> TabAtkins: Just one more bit that you can use to talk to an iframe, and every bit counts
<fantasai> TabAtkins: but if that's considered not too much of a problem, then I'm fine with it
<fantasai> emilio: It's a communication channel in the sense that the SVG could request a different image or something
<fantasai> emilio: but SVG images don't run script
<fantasai> emilio: I think Chrome did something like this for iframes, don't know the details of that
<futhark> q+
<fantasai> emilio: If your iframe is in color-scheme: ? then you force a light background
<fantasai> futhark: Behavior for ?? is specified in the spec, that you set the background of the iframe if 'color-scheme' doesn't match parent
<fantasai> futhark: so you don't wind up with black on black or white on white
<TabAtkins> s/??/iframes with different color scheme than parent document/
<fantasai> futhark: Wanted to ask, has anyone asked for similar functionality for iframe?
<emilio> q+
<fantasai> futhark: or will there be other cases?
<Rossen_> ack futhark
<fantasai> futhark: other than SVG
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to ask why not restrict cross-origin
<fantasai> fantasai: If the concern is cross-origin, why not restrict to same-origin
<fantasai> emilio: Possible, but maybe awkward
<fantasai> emilio: wrt Rune's question, we actually do that for some frames
<fantasai> emilio: e.g. for extension popups in Firefox, they're just iframes inside a popup
<fantasai> emilio: we make those inherit the color scheme of Firefox in a similar fashion
<fantasai> emilio: so we already have this code to make it work for iframes
<fantasai> futhark: We do something similar for <select> popups in Chrome
<fantasai> futhark: If you have <select> with a color scheme, that affects the drop-down render
<fantasai> emilio: This seems generally a useful thing then
<fantasai> emilio: Main question is whether it's reasonable, given the issue Tab mentioned
<fantasai> emilio: I'm not sure I'm the right person to make that assessment
<fantasai> emilio: What about we ask people in privacy/security what they think about this?
<fantasai> emilio: If we accept it, then we can consider doing iframes as well
<fantasai> Rossen_: seems like a reasonable path forward
<fantasai> Rossen_: I think general consensus of the group leans towards the proposal
<fantasai> Rossen_: pending feedback from Security folks
<fantasai> Rossen_: So my proposal is to end the discussion here, and then get back to it as we gather more information
<TabAtkins> Always useful to resolve, if for no other reason than to have a neat conclusion easy to read at the end
<fantasai> fantasai: Could resolve that we want to do this, if reasonable from security standpoint
<fantasai> Rossen_: Any objection to record this as consensus of group?
<fantasai> PROPOSAL: Have prefered-color-scheme reflect 'color-scheme' on the element in the embedding document, to the extent acceptable from security standpoint
<fantasai> RESOLVED: Have prefered-color-scheme reflect 'color-scheme' on the embedding element in the embedding document, to the extent acceptable from security standpoint (pending security review)

emilio · 2022-05-13T14:21:28Z

I just realized that in non-Gecko browsers, this bit of information is already passed down to the right process due to #4772.

…lor schemes. r=jwatt In the future we might want to (also?) propagate the prefers-color-scheme on the iframe like we do for the content/chrome boundary / top browsing contexts, see: * w3c/csswg-drafts#4772 * w3c/csswg-drafts#7213 Differential Revision: https://phabricator.services.mozilla.com/D146162

emilio · 2022-06-01T18:55:29Z

Bringing this up again because I was working on this in https://bugzilla.mozilla.org/show_bug.cgi?id=1738380, and I realized that there's no way to guarantee a transparent background of an iframe without hard-coding the color-scheme.

That is: an iframe with <meta name="color-scheme" content="light dark"> that ideally has both light and dark mode, can be guaranteed to be transparent, if e.g. the user prefers dark theme but it's embedded on a light page.

That's a bit unfortunate, there's a variety of regressions from my work that would ideally be fixed by just having <meta name="color-scheme" content="light dark"> (like https://bugzilla.mozilla.org/show_bug.cgi?id=1771047 / https://bugzilla.mozilla.org/show_bug.cgi?id=1772168), but which instead have to coordinate between embedder and embedee.

@smfr / @lilles / @tabatkins, is there any chance you could ping some of the WebKit / Blink security folks about this (since that's the major concern here)? I'll do the same for Mozilla's security folks, but my guess is that since the relevant information is already in the target process, it's not really a big leak...

heycam · 2022-06-07T07:53:48Z

Would this affect SVG images used as CSS <image> values too?

emilio · 2022-06-07T09:37:25Z

Probably?

smfr · 2022-06-08T03:26:03Z

But I guess you're right that they could trigger different image loads to exfiltrate that bit

It looks like no browser allows an SVG image to load subresources, so maybe this isn't a problem?

smfr · 2022-07-08T18:25:09Z

Maciej pointed out that the HTML spec doesn't actually say that SVG images use "Secure Animated Mode", and that HTML probably needs a central place to define valid image resources as "a non-interactive, optionally animated, image resource that is neither paged nor scripted." https://html.spec.whatwg.org/#image-button-state-(type=image) says "User agents must only display the first page of a multipage resource. User agents must not allow the resource to act in an interactive fashion, but should honor any animation in the resource." but this text should be generalized and shared with things like video poster images in the spec.

If it's clear that SVG images are in "Secure Animated Mode", then I think WebKit is ok allow color-scheme to propagate in.

css-meeting-bot · 2022-07-13T17:02:20Z

The CSS Working Group just discussed [css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent?, and agreed to the following:

RESOLVED: prefers-color-scheme in SVG rendered in secure animated mode is context-dependent

The full IRC log of that discussion

<fantasai> Topic: [css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent?
<fantasai> github: https://github.com//issues/7213
<fantasai> emilio: I did check with the security folks at MOzilla, and they weren't concerned about making this apply even more generally to iframes
<fantasai> emilio: Only attack is if a page is in an iframe and a top-level frame, can determine ???
<fantasai> emilio: But no problem for SVG images
<fantasai> emilio: I think it'd be nice to do it for iframes as well
<fantasai> emilio: My discussion with them was that it's not a big concern, idk if other folks have an opinion
<fantasai> smfr: On the WebKit side would be much more reluctant to do on iframes, but OK for SVG images
<fantasai> smfr: Was having trouble finding text in HTML spec that SVG couldn't run script or load external images
<fantasai> smfr: so part of this issue needs to clarify when SVG can load external resources or run script
<chris> q+
<fantasai> emilio: Why reluctant to make it work on iframes?
<fantasai> emilio: We already communicate info about backgrounds
<fantasai> smfr: I'd have to go back and ask the security ppl
<astearns> ack chris
<fantasai> chris: SVG images in <img> tag don't run scripts or fetch resources
<dholbert> smfr: RE where it's defined that SVG Images don't run scripts, that's defined in https://svgwg.org/specs/integration/
<fantasai> chris: if they are in <object> they can fetch and run script
<fantasai> chris: It's not a function of SVG, but function of SVG's integration in external environment and what it allows them to do
<dholbert> see https://svgwg.org/specs/integration/#secure-animated-mode
<fantasai> astearns: When in <object> ...
<dholbert> "Secure animated mode"
<fantasai> chris: They can do everything
<fantasai> astearns: Are they SVG images?
<fantasai> chris: Yes, just not using an <img> tags
<smfr> dholbert: but HTML doesn’t reference that everywhere it needs to
<fantasai> emilio: From implementation point of view, they are iframes
<TabAtkins> (as far as I recall) Chrome is fine with passing into any SVG that can't fetch or run script (aka <img> tags), and same-origin iframes.
<fantasai> chris: Also if displayed standalone, same thing
<fantasai> chris: they can run scripts, fetch resources, etc.
<TabAtkins> We just don't want to open up new cross-origin communication bits.
<fantasai> emilio: Seems there would be no objection to doing on SVG images
<fantasai> emilio: and maybe file an issue about iframes
<fantasai> smfr: Sounds good
<astearns> ack TabAtkins
<fantasai> TabAtkins: from what I recall, Chrome is fine with this so long as it doesn't open up new cross-origin communication bits
<fantasai> TabAtkins: So SVG as img should be fine
<fantasai> TabAtkins: and same-origin iframe should be fine
<fantasai> smfr: That matches WebKit's preference, too
<fantasai> emilio: OK, then we can discuss iframes separately
<fantasai> emilio: I'm more interested in this SVG case
<fantasai> emilio: It's not easy for the iframe to tell where the preference comes from
<fantasai> emilio: we can discuss another time
<astearns> ack fantasai
<Zakim> fantasai, you wanted to propose resolution
<fantasai> fantasai: Seems we have consensus on SVG as <img> and also same-origin iframe
<fantasai> ???: what about SVG's that are rendered through CSS?
<fantasai> fantasai: There's an embedding mode for SVG that does this, so anything in that embedding mode
<fantasai> astearns: Maybe let's take a resolution on SVG first
<fantasai> emilio: draw background in iframes, that doesn't care about same vs cross-origin, so unsure how to do that
<fantasai> astearns: proposed that prefers-color-scheme in SVG-images is context-dependent
<fantasai> smfr: "SVG rendered in secure animated mode"
<smfr> https://svgwg.org/specs/integration/#secure-animated-mode
<fantasai> astearns: objections?
<fantasai> RESOLVED: prefers-color-scheme in SVG rendered in secure animated mode is context-dependent
<fantasai> Meeting closed.
<astearns> zakim, end meeting
<Zakim> As of this point the attendees have been flackr, bramus, emilio, dholbert, rachelandrew, argyle, dbaron, alisonmaher, TabAtkins, plinss, jfkthame, chrishtr, jensimmons, GameMaker,
<Zakim> ... oriol, faceless, fantasai, bkardell_, dandclark, lea, bradk, tantek, hober
<Zakim> RRSAgent, please draft minutes v2
<RRSAgent> I have made the request to generate https://www.w3.org/2022/07/13-css-minutes.html Zakim
<Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye

As per discussion in w3c/csswg-drafts#7213. Differential Revision: https://phabricator.services.mozilla.com/D151751 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1779457 gecko-commit: 33fbecca098c163ff086113225f580d67a53c611 gecko-reviewers: aosmond

…on content too. r=aosmond As per discussion in w3c/csswg-drafts#7213. Differential Revision: https://phabricator.services.mozilla.com/D151751

As per discussion in w3c/csswg-drafts#7213. Differential Revision: https://phabricator.services.mozilla.com/D151751 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1779457 gecko-commit: 33fbecca098c163ff086113225f580d67a53c611 gecko-reviewers: aosmond

…on content too. r=aosmond As per discussion in w3c/csswg-drafts#7213. Differential Revision: https://phabricator.services.mozilla.com/D151751

…scheme of the embedding node for prefers-color-scheme. #7213

tabatkins · 2022-08-24T21:31:10Z

All right, embedded SVG text added to MQ5. Left a note about us still discussing this for iframes.

emilio · 2022-08-24T21:59:52Z

We resolved for iframes in #7493 didn't we?

tabatkins · 2022-08-25T00:42:51Z

Ah, we did! Thanks, I'll fix it up then.

bramus · 2023-07-17T22:26:06Z

Closing this issue as the necessary edits have made it in. Added the necessary labels to #7493, which is concerned with the behavior for iframes.

Note that due to https://bugzilla.mozilla.org/show_bug.cgi?id=1779457 / w3c/csswg-drafts#7213, prefers-color-scheme works fine even if the user has an explicitly light theme or so.

Note that due to https://bugzilla.mozilla.org/show_bug.cgi?id=1779457 / w3c/csswg-drafts#7213, prefers-color-scheme works fine even if the user has an explicitly light theme or so. This fixes mozilla#2583 too.

Note that due to https://bugzilla.mozilla.org/show_bug.cgi?id=1779457 / w3c/csswg-drafts#7213, prefers-color-scheme works fine even if the user has an explicitly light theme or so. This fixes mozilla#2583 entirely.

emilio added the mediaqueries-3 label Apr 13, 2022

emilio added the Agenda+ label Apr 13, 2022

css-meeting-bot removed the Agenda+ label Apr 20, 2022

mozilla-apprentice mentioned this issue Apr 20, 2022

[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent? mozilla/wg-decisions#774

Open

emilio added the Agenda+ label Jun 1, 2022

emilio mentioned this issue Jun 10, 2022

[mediaqueries-5] Script control of (prefers-*) queries #6517

Open

css-meeting-bot removed the Agenda+ label Jul 13, 2022

mozilla-apprentice mentioned this issue Jul 13, 2022

[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent? mozilla/wg-decisions#827

Closed

emilio mentioned this issue Jul 13, 2022

[css-mediaqueries] Should prefers-color-scheme in iframes be context-dependent? #7493

Open

moz-wptsync-bot mentioned this issue Jul 14, 2022

[Gecko Bug 1779457] Make prefers-color-scheme of SVG images match embedder on content too. web-platform-tests/wpt#34845

Merged

emilio mentioned this issue Jul 22, 2022

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

Open

dholbert mentioned this issue Aug 2, 2022

Provide a way to pass theming colors (and potentially other info) into SVG images, via e.g. Tab's SVG Parameters spec #6988

Closed

hamishwillee mentioned this issue Aug 12, 2022

[CSS] prefers-color-scheme reflects the color-scheme on the embedding element mdn/content#19449

Closed

10 tasks

tabatkins added a commit that referenced this issue Aug 24, 2022

[mediaqueries-5] Per WG resolution, embedded SVGs use the used color …

447e4de

…scheme of the embedding node for prefers-color-scheme. #7213

bsmth mentioned this issue Oct 6, 2022

19449 prefers color scheme mdn/content#20886

Merged

bramus added the Closed Accepted by CSSWG Resolution label Jul 17, 2023

bramus closed this as completed Jul 17, 2023

frivoal added mediaqueries-5 and removed mediaqueries-3 labels May 14, 2024

JoshTumath mentioned this issue Aug 15, 2024

[mediaqueries] Effect of <meta name=color-scheme> on the (prefers-color-scheme) MQ #10249

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent? #7213

[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent? #7213

emilio commented Apr 13, 2022

emilio commented Apr 13, 2022

tabatkins commented Apr 14, 2022

emilio commented Apr 14, 2022

lilles commented Apr 20, 2022

emilio commented Apr 20, 2022

css-meeting-bot commented Apr 20, 2022

emilio commented May 13, 2022

emilio commented Jun 1, 2022

heycam commented Jun 7, 2022

emilio commented Jun 7, 2022

smfr commented Jun 8, 2022

smfr commented Jul 8, 2022

css-meeting-bot commented Jul 13, 2022

tabatkins commented Aug 24, 2022

emilio commented Aug 24, 2022

tabatkins commented Aug 25, 2022

bramus commented Jul 17, 2023

[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent? #7213

[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent? #7213

Comments

emilio commented Apr 13, 2022

emilio commented Apr 13, 2022

tabatkins commented Apr 14, 2022

emilio commented Apr 14, 2022

lilles commented Apr 20, 2022

emilio commented Apr 20, 2022

css-meeting-bot commented Apr 20, 2022

emilio commented May 13, 2022

emilio commented Jun 1, 2022

heycam commented Jun 7, 2022

emilio commented Jun 7, 2022

smfr commented Jun 8, 2022

smfr commented Jul 8, 2022

css-meeting-bot commented Jul 13, 2022

tabatkins commented Aug 24, 2022

emilio commented Aug 24, 2022

tabatkins commented Aug 25, 2022

bramus commented Jul 17, 2023