See the discussions from https://github.com/w3c/csswg-drafts/issues/4772. I'm not sure what we want to do here specially wrt cross-origin iframes.

Hi Emilio! Do you know if Firefox plans to implement https://www.w3.org/TR/css-color-adjust-1/#color-scheme-effect like e.g. Chrome did?

in the case of embedded documents typically rendered over a transparent canvas (such as provided via an HTML iframe element), if the used color scheme of the element and the used color scheme of the embedded document’s root element do not match, then the UA must use an opaque canvas of the Canvas color appropriate to the embedded document’s used color scheme instead of a transparent canvas

We'd need something like that for our use case, which looks like:

We have an iframe that can show completely arbitrary content (from thousands of authors), from a cross-origin. We'd like to either a) make the iframe opaque at all times (not possible as far as I understand) or b) make it opaque when its color-scheme is dark.

The second solution means using a style like this in the parent document:

.preview-iframe {
  color-scheme: light;
  background-color: white;
}

Because having a white background — even when using our app's dark theme — is a good default given the majority of arbitrary author content that we render in this preview iframe. But then it breaks when the iframe document has a dark Used Color Scheme and ends up with white text. Signaling that the iframe renders in a light color scheme context fixes this issue for us in Chrome, but not in Firefox at this time.

Hmm, so this still feels a bit fishy to do in cross-origin iframes... Also, If we were to communicate that bit to cross-origin iframes, I'd rather just inherit the used color-scheme as the preferred color scheme (https://github.com/w3c/csswg-drafts/issues/7213), which is what we do for a bunch of frames in popups and so internally in Firefox.

That should also fix it, right? (because the used color-scheme would be light in that case).

Also, WebKit behaves like Gecko here, right? At least it did when I filed this bug, IIRC.

So... Just to make sure I understand your use-case, the issue is that you don't know if the previewed content will end up honoring the preferred color-scheme, right? So, setting a white background works for content that doesn't honor it, and breaks content that does, and not setting it breaks content that doesn't honor it, but doesn't break content that does. Is my understanding correct?

If you're in control of the content you embed, you could use :root { background-color: Canvas }, right?

So... Just to make sure I understand your use-case

I think you got it right. Not 100% sure about the meaning of “honoring” here, but in practice that's the issue we have yeah. Or more generally: transparent iframes where the embedded document has no background color and uses some arbitrary text color, either explicitly (the document author set some text colors) or as a reaction to the OS color scheme.

Historically we could predict that users expected web pages to have a white background, and if they wanted a dark theme they would author their pages to set the page's text and background colors. So we had a white background behind our iframes. But <meta name="color-scheme" content="dark"> throws a wrench in that heuristic, because then authors may rely on the browser to set the page's background, which works for top-level documents but not in iframes. And we end up with white text on a white background. And changing our background would break more content than it would fix.

I have a longer write-up of this issue on my blog: https://fvsch.com/transparent-iframes

If you're in control of the content you embed

We're not: for a good fraction of projects we run, it's 100% user-generated HTTP responses.

For “classic” StackBlitz projects we do generate the HTML page shown in the iframe and inject user-generated code into it.
But for projects based on our WebContainers tech, which runs Node.js code in the browser (including in Firefox now, in an alpha capacity), we're showing HTTP responses generated by Node-based development tools and servers such as express, webpack-dev-server, vite or Next.js (and hundreds of others).

If we were to communicate that bit to cross-origin iframes

Would it be communicated if the browser sets an opaque background for the iframe?

I can't seem to get that information in Chrome.

1. The used color scheme in the embedded document doesn't depend on the parent document, or on whether the parent document uses a matching or mismatching color scheme.
2. I don't think (prefers-color-scheme) would be impacted either?
3. In my tests, the computed background-color for the iframe's root element seems to always be rgba(0, 0, 0, 0), regardless of if the browser applied an opaque background for the document or not.

So it doesn't seem to leak any additional info to the third-party document (unless I missed it, because I don’t know this stuff super well ^^).

Also, WebKit behaves like Gecko here, right?

Not according to https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme?label=experimental&label=master&aligned

By the way, the solution we ended up deploying (update deployed yesterday) is:

.preview-iframe {
  color-scheme: light;
  background-color: white;
}

The top-level document may have :root { color-scheme: dark } or :root { color-scheme: light } depending on the editor theme selected by the user, but we're telling the browser that the preview iframe is always rendered in a “light” context (since it always has a white background, for compability with the majority of user content).

This works well in Chrome 101 and Safari 15.4 in my tests; no impact in Firefox (so a HTML page with color-scheme: dark and no explicit background color would render with white text on top of our white background).

(In reply to Florens Verschelde :fvsch from comment #5)

Would it be communicated if the browser sets an opaque background for the iframe?

Yes you need to.

I can't seem to get that information in Chrome.

1. The used color scheme in the embedded document doesn't depend on the parent document, or on whether the parent document uses a matching or mismatching color scheme.
2. I don't think (prefers-color-scheme) would be impacted either?
3. In my tests, the computed background-color for the iframe's root element seems to always be rgba(0, 0, 0, 0), regardless of if the browser applied an opaque background for the document or not.

So it doesn't seem to leak any additional info to the third-party document (unless I missed it, because I don’t know this stuff super well ^^).

I mean communicated as in "sent to the embedded process". Even if it's not exposed to web developers

Also, WebKit behaves like Gecko here, right?

Not according to https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme?label=experimental&label=master&aligned

Huh, I'm pretty sure at the time I looked at this. It seems it was fixed in https://bugs.webkit.org/show_bug.cgi?id=228124 but that was probably not in the Safari release I was testing. Alas

https://hg.mozilla.org/mozilla-central/rev/f0c4c97a8e6a