W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2020

Re: [csswg-drafts] [css-color-adjust-1] Should probably not honor non-url background images (#4916)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 10 Jun 2020 16:54:48 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-642134981-1591808087-sysbot+gh@w3.org>
The CSS Working Group just discussed `[css-color-adjust-1] Should probably not honor non-url background images`, and agreed to the following:

* `RESOLVED: Do not honor non-URL background images in forced color adjustments`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-color-adjust-1] Should probably not honor non-url background images<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4916<br>
&lt;dael> emilio: When we impl we initially allowed all bg images like spec says. We had to revert and only allow url based bc/ things like gradients cause undesired effects. High contrast dark theme with white gradient you don't want to show<br>
&lt;dael> emilio: Not sure what Edge or new blink impl does, but we got a lot of complaints from high contrast users<br>
&lt;dael> AmeliaBR: End user pov gradients act more like background color than bg image which we'd preserve?<br>
&lt;dael> emilio: Right<br>
&lt;dael> Rossen_: Current impl is evolving in this respect<br>
&lt;dael> Rossen_: Issue you raised I checked one of the linked URLs. I didn't see why that didn't repro the issue.<br>
&lt;dael> Rossen_: Regardless two options you listed which is not honor or do something further and allow alpha blending of non-color bg to blend with override from system colors. That's an interesting approach but not sure effect on gradients and if that's more desirable<br>
&lt;dael> Rossen_: Either approach seems reasonable.<br>
&lt;dael> Rossen_: Before the call smfr linked to a prop from dino a while back<br>
&lt;dael> smfr: Linked b/c had a mech to desc how change colors and gradients. Instead of magic text you can say color-fliter-saturation:0<br>
&lt;dael> Rossen_: Defined BG color as a color-mix to be able to blend with computed color of system colors. That's the case and I was thinking if the color mix would be enough in this case<br>
&lt;dael> emilio: Need to color mix all colors in image. color-filter more tricky b/c if applies to system colors it's opposite. Need to prevent it from applying to UA colors which is not ideal<br>
&lt;dael> smfr: Had notion in webkit, but I don't think we specified anything on it<br>
&lt;dael> emilio: Doesn't that mean default color isn't filtered? I guess it depends<br>
&lt;dael> Rossen_: Could go more restrictive and not honor non-url bg images and than figure out if we can alpha-blend gradients<br>
&lt;dael> emilio: sgtm<br>
&lt;dael> astearns: Prop: Not honor non-url bg images for color adjustments<br>
&lt;dael> astearns: Or non-URL bg images people can use color adjustment MQ to make own changes?<br>
&lt;dael> fantasai: NO b/c we're not allowing them<br>
&lt;dael> astearns: But you can have rules in stylesheet o use differen gradients<br>
&lt;dael> AmeliaBR: Same as forced-color changing any other forced-color rule. It turns off forced color on certain element<br>
&lt;dael> fantasai: But that turns off all riles which is next issue<br>
&lt;fantasai> s/riles/rules/<br>
&lt;dael> astearns: Any objections to Not honor non-URL bg images in color-adjustments?<br>
&lt;dael> AmeliaBR: Can you say forced color?<br>
&lt;dael> Prop: Do not honor non-URL bg images in forced color adjustments<br>
&lt;dael> fantasai: I'm okay with it to start. Looking at other ideas in issue might be worthwhile, but we can start here<br>
&lt;dael> Rossen_: Agree. I think this is a reasonable first step on the path<br>
&lt;dael> RESOLVED: Do not honor non-URL background images in forced color adjustments<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4916#issuecomment-642134981 using your GitHub account
Received on Wednesday, 10 June 2020 16:54:50 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:27:12 UTC