w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.5k stars 661 forks source link

[css-color-adjust] viewport propagation of forced-color-adjust #6307

Closed alisonmaher closed 3 years ago

alisonmaher commented 3 years ago

We propagate background-color from the root/body to the viewport. However, we don't similarly propagate forced-color-adjust, which can lead to unexpected results in forced colors mode.

For example, in the following case, we propagate a background-color of red to the viewport in forced colors mode because forced-color-adjust is set to none. However, because colors are now forced at used value time, when we re-resolve the background color at the viewport, we end up forcing the background to Canvas, since forced-color-adjust at the viewport computes to auto.

<style>
  :root {
    background-color: red;
    forced-color-adjust: none;
  }
</style>

The proposal would be to propagate forced-color-adjust to the viewport, as well, since the used value of background-color is dependent on forced-color-adjust.

It was resolved in issue #6079 that "No future properties should propagate from body". So, if we decide to only propagate forced-color-adjust from the root and not the body, are we ok with the following case resulting in a non-red background in forced colors mode?

<style>
  body {
    background-color: red;
    forced-color-adjust: none;
  }
</style>
css-meeting-bot commented 3 years ago

The CSS Working Group just discussed [css-color-adjust] viewport propagation of forced-color-adjust.

RESOLVED: Add forced-color-adjust propagation to apply to root

The full IRC log of that discussion <dael> Topic: [css-color-adjust] viewport propagation of forced-color-adjust
<dael> github: https://github.com/w3c/csswg-drafts/issues/6307
<dael> alisonmaher: Currently prop from root and body to viewport. Since we force colors at used value time we can get wrong if don't prop forced-color-adjust to viewport
<dael> alisonmaher: We previously resolved not to prop any new properties from body to viewport but wondering if we should have an acception here so forced color does prop when set on body
<dael> TabAtkins: I see argument for it.
<dael> TabAtkins: As not a direct implementer I can't say if it's cool to add one more to the list, but I can see why it's confusing to figure out when color comes off body
<dael> Rossen_: Effect of not doing it? You may have bg of viewport that's different than forced?
<dael> alisonmaher: Set forced-color:adjust to none and want bg to be another color we would end up forcing the viewport bg color b/c it's not none at viewport. Wouldn't get bg color at the viewport
<futhark> q+
<dael> fantasai: Two comments. Seems bad practice to set forced-color-adjust none on body. Seems a bit user hostile to say I don't care what you want
<dael> fantasai: If concern is tweak color of bg we have similar problem with color scheme. If we prop one we should prop both. Not sure we should; we should encourage people to set in html
<dael> alisonmaher: If we were to do it for forced-color-adjust doing it for color-scheme would make sense as well
<Rossen_> ack futhark
<dael> futhark: I was thinking that is it really we should prop the property to viewport and not we should take into acocunt when prop. When try and prop bg we look at display value and if it's display:none it's not prop. Maybe similar
<dael> alisonmaher: Yeah, when look at f-c-s at used value time we could end up forcing hte prop value of viewport no matter what.
<dael> s/f-c-s/forced-color-adjust
<dael> Rossen_: Are options to leave as-is and use this as a soft mechanism to discourage such usage patterns by authors? otoh we can still add that same question applies to do we add back color scheme to the list
<dael> alisonmaher: Those are two options. One use case from author to set a bg color for svg image which are similar to root and viewport prop. To fix that we would need to prop from root to viewport. Hoping can resolve on prop from root. If doing for root might makes sense to do from body as well
<dael> Rossen_: Other opinions?
<dael> fantasai: If we're doing from root make sense to do from body as well statement doesn't make sense. Have lot of properties that prop from root but not body so don't think that holds
<dael> alisonmaher: If feel we shouldn't do from body I'm okay with that. Root piece is major thing looking for. Can see author confusion but wouldn't object
<emilio> +1 for doing it just for the root
<dael> fantasai: A bunch of scrolling properties that don't prop from body. We locked down to some css 2 properties
<fantasai> s/from body/from body even though overflow does/
<dael> Rossen_: Not hearing disagreement about root. Sounds reasonable. Convo seems to support adding to root. For body we've been making steady attempts to min exposure that's prop.
<dael> Rossen_: Sounds like current consensus is around adding to root but not body.
<dael> alisonmaher: That works
<dael> Rossen_: Other thoughts?
<dael> Rossen_: Obj to adding forced-color-adjust propagation to apply to root
<dael> RESOLvED: Add forced-color-adjust propagation to apply to root
<oriol> Note in https://github.com/w3c/csswg-drafts/issues/6079#issuecomment-816307011 we resolved "No future properties should propagate from <body> to the ICB"
fantasai commented 3 years ago

@alisonmaher Edits checked in, let us know if it looks OK!

alisonmaher commented 3 years ago

@fantasai Looks good to me, thanks!