- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 16:37:53 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] Using plus-darker if prefers-color-scheme: dark`, and agreed to the following: * `RESOLVED: Copy the element's used color-scheme value to its ::view-transition-group` * `RESOLVED: ::view-transition-group uses plus-lighter or plus-darker, based on the color-scheme (mechanism TBD)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> vmpstr: In VT spec we use the plus-lighter blending mode to combine the old and new snapshots<br> <TabAtkins> vmpstr: This basically ensures that if the images are the same they'll look the same as you crossfade opacity<br> <TabAtkins> vmpstr: If they're not the same, they'll tend to be somewhat lighter than the source images<br> <TabAtkins> vmpstr: That looks fine in light mode, but in dark mode they can end up a lot brighter than expected<br> <vmpstr> https://github.com/w3c/fxtf-drafts/issues/447#issuecomment-1699293766<br> <TabAtkins> vmpstr: So we propose using the MQ in the issue - if the color scheme pref is dark, use plus-darker instead<br> <TabAtkins> vmpstr: dbaron has put an issue in the chat about changing the formula for plus-darker<br> <TabAtkins> vmpstr: This MQ for preferring dark doesn't need to be repsected by the site, so it might make things dark on a light page<br> <TabAtkins> vmpstr: I think that's fine, the user prefers that the page look darker and we're making the transition image darker.<br> <emilio> q+<br> <TabAtkins> vmpstr: But in general I don't think we can detect what the page is doing<br> <fremy> q+<br> <astearns> ack emilio<br> <TabAtkins> emilio: You can kinda detect what the page is doing if you look at the used color-scheme property, right?<br> <fantasai> +1<br> <futhark> +1<br> <TabAtkins> emilio: All pages that respect prefers-color-scheme might not use the <meta> or set color-scheme on the root, but I hope most do<br> <khush> q+<br> <TabAtkins> astearns: So if the MQ and the color-scheme are dark?<br> <TabAtkins> emilio: You can set the used color-scheme to be different from the prefers color-scheme<br> <TabAtkins> emilio: But the color-scheme already takes the preference into account<br> <astearns> ack fremy<br> <TabAtkins> fremy: I think this could also be done per element<br> <TabAtkins> fremy: If you have part of your site that's light theme, might want to use plus-lighter on that element while plus-darker on the dark rest of the page<br> <TabAtkins> fremy: So I think using color-scheme is the better way, per element<br> <TabAtkins> fremy: It ensures authors are using color-scheme, and it gives them control over what it applies to<br> <astearns> ack khush<br> <TabAtkins> khush: Want to echo point from Vlad, even if page isn't respecting user's color scheme it still makes sense to use plus-darker bc it's what the author is preferring<br> <TabAtkins> khush: So even if the page didn't respect color-scheme we'd respect the author pref<br> <TabAtkins> khush: So maybe it should be an OR - if user pref is dark, *or* the element's color-scheme is dark, use plusdarker<br> <TabAtkins> fremy: Unsure if that's good, if authors can't control...<br> <TabAtkins> vmpstr: Authors can control which blending mode to use, this is just the default<br> <dbaron> s/can control/can control with the pseudos/<br> <TabAtkins> fremy: Probably also depend son how strong a difference the visual change is<br> <TabAtkins> fremy: If it's a subtle difference it doesn't matter as much vs being very visible<br> <TabAtkins> astearns: One option is to punt for now, since plus-darker isn't interoperable and we need people to use VT to see if it makes a huge diff with color-scheme anyway. We can also see if authors are overriding default just for color-scheme.<br> <TabAtkins> astearns: So maybe we wait and find out<br> <eeeps> q+<br> <TabAtkins> vmpstr: I think I'd prefer to at least respect the color-scheme for now<br> <TabAtkins> vmpstr: I think i've reconsidered using the MQ. color-scheme seems like a strong signal that the page is indeed using a dark color scheme<br> <TabAtkins> vmpstr: So using that as the default makes sense, I think<br> <astearns> ack eeeps<br> <TabAtkins> eeeps: So to udnerstand the problem, in theory if you could interpolate the pixel values you wouldn't need to look at color scheme?<br> <TabAtkins> vmpstr: Issue is in order to cross-fade, if they're the same image you don't want it to look different. So you need a blending mode that's one of the pluses<br> <TabAtkins> vmpstr: So plus-lighter is one of these, but it tends to lean lighter.<br> <astearns> ack dbaron<br> <TabAtkins> dbaron: This is probably the sort of somewhat-subtle thing where even if devs see it and think it looks a little funny, they're not necessarily gonna know how to fix it<br> <TabAtkins> dbaron: So I'm a little skeptical of the "wait and see" suggestion.<br> <TabAtkins> dbaron: Think even if they don't do it a lot it's not a strong signal against.<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: I think we should do this based only on color-scheme not on MQ.<br> <TabAtkins> fantasai: And on the color-scheme of the element originating the VT, consistently for the entire tree.<br> <TabAtkins> q+<br> <TabAtkins> fantasai: So I propose we add a new keyword to blending mode that does this<br> <fantasai> s/keyword/keyword (plus-auto)/<br> <emilio> TabAtkins: I disagree that we should do it on the element originating the transition<br> <astearns> +1<br> <emilio> ... as a benefit this could be implemented just with the light-dark() function we resolved a bit ago<br> <emilio> khush: what's that?<br> <emilio> TabAtkins: light-dark() returns one of two values if either is light or dark<br> <emilio> fantasai: that's a color<br> <emilio> TabAtkins: sure, light-dark-value() :)<br> <TabAtkins> khush: So say I have a funciton that picks one of these two values, what element does it come from?<br> <TabAtkins> khush: Here it would come from th epseudo-element, which inherits from the originating element.<br> <fantasai> mmmm that's not right at all<br> <TabAtkins> khush: But we can copy the color-scheme from the transitioning element to the pseudo and get it work correctly<br> <fantasai> that's correct<br> <TabAtkins> astearns: So proposed resolution is we copy the element's color-scheme to its ::view-transition-group<br> <TabAtkins> fremy: What happens if the initial page was light mode and next is dark mode?<br> <astearns> s/color-scheme/used color-scheme value/<br> <TabAtkins> khush: It takes the latest value, we ahve that with a lot of values already<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: Copy the element's used color-scheme value to its ::view-transition-group<br> <TabAtkins> vmpstr: We also need to use this color-scheme to set the blend mode<br> <fantasai> mix-blend-mode: light-dark(plus-lighter, plus-darker)<br> <fantasai> s/light-dark/light-dark-value/<br> <fantasai> PROPOSED: mix-blend-mode on ::view-transition-group takes light-dark-value(plus-lighter, plus-darker)<br> <TabAtkins> proposed: ::view-transition-group uses plus-lighter or plus-darker, based on the color-scheme<br> <TabAtkins> (mechanism TBD)<br> <TabAtkins> RESOLVED: ::view-transition-group uses plus-lighter or plus-darker, based on the color-scheme (mechanism TBD)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9276#issuecomment-1719786830 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 September 2023 16:37:55 UTC