[csswg-drafts] [css-color-adjust-1] interaction between propagation and forced-color adjustment (#12168)

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

== [css-color-adjust-1] interaction between propagation and forced-color adjustment ==
Consider:

```html
<!DOCTYPE html>
<html><head>
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<style>
html, body { margin: 0; padding: 0; font-size: 36px; }
html { forced-color-adjust: none; }
body { forced-color-adjust: auto; background: red; }
</style>
</head><body>
</body>
</html>
```

Suppose `red` is not a system color, then:

- Per https://www.w3.org/TR/css-color-adjust-1/#forced-colors-properties, forced-color adjustment changes used values, not computed values (unless inherited with `forced-color-adjust: preserve-parent-color`). Therefore, the computed values follow normal rules. The computed `background-color` of `html`, `body` are `transparent`, `red`. Moreover, the computed `background-image` of `html`, `body` are both `none`. According to the adjustment rules, **the used background of `body` is `Canvas` in this case.**
- Per https://drafts.csswg.org/css-backgrounds/#body-background, when the computed `background-color`, `background-image` of `html` are `transparent`, `none`, the computed background properties of `body` are propagated to `html` (as if they were "specified"), and **the used background of `body` is initial value, which is `transparent`.** Note that the propagated specified values to `html` become computed values.

We reach a contradiction on the used background of `body`. The order of propagation and adjustment should be specified.

In addition, regardless of the used background on `body`:

- The computed background of `html` becomes `red`, and its `forced-color-adjust` is `none`, so it should be red.

However, MSEdge 136.0.3240.50 (Official build) (64-bit) will show `Canvas` background. Would you suggest that I file an issue with Chromium? (I don't suggest myself reporting that as a bug.)

---

I feel the correct definition should be this:

1. The background on `body` is computed, then potentially adjusted, arriving at a used value.
2. If the computed background on `html` is `transparent`, then it acquires the **used** background from `body` (not the computed of `body`) as its own **computed** value and forcibly resets `body` to `transparent` background. Potentially, the background of `html` undergoes adjustment from its computed value (either propagated or cascaded).

I'll call the propagation condition "`html` has trivial `background`". Enumerate the scenarios for my proposed definition:

- `html` has trivial `background`, either or both have adjustment, then the overall result is `Canvas` background.
- `html` has trivial `background`, neither has adjustment, then the overall result is developer-specified background from `body`.
- `html` has non-trivial `background`, then the canvas background directly determined by `html` (considering `html` willingness to adjust).

In all cases, the result is intuitive (and consistent with what MSEdge currently does).

Note that in the proposed definition, in the second step, whether the forcible reset of `body` to `transparent` is followed by another potential adjustment on `body`, is academic and not interesting:

- Per CSS color-adjust-1, upon adjustment, the background color retains its alpha channel. Therefore, the body background simply becomes another transparent color. There is no difference in rendered result.
- Keeping `body` simply `transparent` reenforces the (correct) idea that setting **one** `background` on either `html` or `body` simply sets the canvas background. The range of this background has nothing to do with the bounds of `html` or `body`.


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


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

Received on Tuesday, 6 May 2025 18:16:01 UTC