[csswg-drafts] [css-color-adjust] about:blank causes undesired flickering with dark color scheme. (#9624)

emilio has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color-adjust] about:blank causes undesired flickering with dark color scheme. ==
See the test-case [here](https://crisal.io/tmp/iframe-flicker.html), with dark mode enabled. This happens across browsers, and per spec, and seems pretty unfortunate to me. For reference:

```
<!doctype html>
<meta charset="utf-8">
<meta name="color-scheme" content="light dark">
<p>Shouldn't see any flickering</p>
<button onclick="reload()">Reload iframe</button>
<div id="target"></div>
<script>
let target = document.getElementById("target");
function reload() {
  target.firstChild?.remove();
  let iframe = document.createElement("iframe");
  iframe.src = `data:text/html,<meta name="color-scheme" content="light dark">`;
  target.appendChild(iframe);
}
</script>
```

The issue is that the initial `about:blank` document, which can get rendered for a split second, but maybe more if the real iframe takes longer to load, or maybe forever if you just have an `<iframe></iframe>` and the website injects content, matches [this condition](https://drafts.csswg.org/css-color-adjust/#color-scheme-effect) in the spec:

> In order to preserve expected color contrasts, in the case of embedded documents typically rendered over a transparent [canvas](https://www.w3.org/TR/CSS21/intro.html#canvas) (such as provided via an HTML [iframe](https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element) element), if the [used color scheme](https://drafts.csswg.org/css-color-adjust/#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](https://drafts.csswg.org/css-color-4/#valdef-system-color-canvas) color appropriate to the embedded document’s used color scheme instead of a transparent canvas. This rule does not apply to documents embedded via elements intended for graphics (such as [img](https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element) elements embedding an SVG document).

Authors can work around it for iframes injected dynamically via `visibility` or so, but that's a bit of a hack.

There ways to fix this like:

 * If it's an (initial only, maybe?) `about:blank` document, assume something equivalent to `<meta name="color-scheme" content="light dark">`. This could in theory break some pages that are doing `<iframe></iframe>` and then appending stuff to the `contentDocument`, so it might not be super-web-compatible, but it's not so risky with https://github.com/w3c/csswg-drafts/issues/4772 since for pages not using `color-scheme`, the iframe will get a preferred scheme of light...
 * Maybe doing that only while there's an ongoing load somehow?
 * Maybe something else?

I think the first suggestion is likely to be web compatible and is the simplest, but let me know if you have other ideas, or somehow this doesn't seem worth fixing or what not.

cc @lilles @tabatkins @smfr @tomayac

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9624 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 22 November 2023 16:40:40 UTC