[css-view-transitions-1] Using plus-darker if prefers-color-scheme: dark

[vmpstr]

In view transitions, we currently use mix-blend-mode: plus-lighter for blending/cross-fading two images. However, this may produce lighter-than-expected results, which stands out particularly in dark color scheme mode.

Perhaps we can consider using plus-darker in these situations, which I believe favors darker colors. I don't know if there's a better check than prefers-color-scheme: dark, but that seems like a good check to flip plus-lighter to plus-darker and back.

[khushalsagar]

prefers-color-scheme is info from browser to developer that users prefer dark mode. Doesn't mean that the author has actually changed the page to support dark mode. And we want plus-darker if the site is designed with a dark color scheme. So we can let authors override the mix-blend-mode if they're supporting dark mode?

[khushalsagar]

Also, this issue requires w3c/fxtf-drafts#447 (comment) to be resolved so plus-darker is compatible across browsers.

[css-meeting-bot]

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)

The full IRC log of that discussion

<TabAtkins> vmpstr: In VT spec we use the plus-lighter blending mode to combine the old and new snapshots
<TabAtkins> vmpstr: This basically ensures that if the images are the same they'll look the same as you crossfade opacity
<TabAtkins> vmpstr: If they're not the same, they'll tend to be somewhat lighter than the source images
<TabAtkins> vmpstr: That looks fine in light mode, but in dark mode they can end up a lot brighter than expected
<vmpstr> https://github.com/w3c/fxtf-drafts/issues/447#issuecomment-1699293766
<TabAtkins> vmpstr: So we propose using the MQ in the issue - if the color scheme pref is dark, use plus-darker instead
<TabAtkins> vmpstr: dbaron has put an issue in the chat about changing the formula for plus-darker
<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
<TabAtkins> vmpstr: I think that's fine, the user prefers that the page look darker and we're making the transition image darker.
<emilio> q+
<TabAtkins> vmpstr: But in general I don't think we can detect what the page is doing
<fremy> q+
<astearns> ack emilio
<TabAtkins> emilio: You can kinda detect what the page is doing if you look at the used color-scheme property, right?
<fantasai> +1
<futhark> +1
<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
<khush> q+
<TabAtkins> astearns: So if the MQ and the color-scheme are dark?
<TabAtkins> emilio: You can set the used color-scheme to be different from the prefers color-scheme
<TabAtkins> emilio: But the color-scheme already takes the preference into account
<astearns> ack fremy
<TabAtkins> fremy: I think this could also be done per element
<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
<TabAtkins> fremy: So I think using color-scheme is the better way, per element
<TabAtkins> fremy: It ensures authors are using color-scheme, and it gives them control over what it applies to
<astearns> ack khush
<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
<TabAtkins> khush: So even if the page didn't respect color-scheme we'd respect the author pref
<TabAtkins> khush: So maybe it should be an OR - if user pref is dark, *or* the element's color-scheme is dark, use plusdarker
<TabAtkins> fremy: Unsure if that's good, if authors can't control...
<TabAtkins> vmpstr: Authors can control which blending mode to use, this is just the default
<dbaron> s/can control/can control with the pseudos/
<TabAtkins> fremy: Probably also depend son how strong a difference the visual change is
<TabAtkins> fremy: If it's a subtle difference it doesn't matter as much vs being very visible
<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.
<TabAtkins> astearns: So maybe we wait and find out
<eeeps> q+
<TabAtkins> vmpstr: I think I'd prefer to at least respect the color-scheme for now
<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
<TabAtkins> vmpstr: So using that as the default makes sense, I think
<astearns> ack eeeps
<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?
<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
<TabAtkins> vmpstr: So plus-lighter is one of these, but it tends to lean lighter.
<astearns> ack dbaron
<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
<TabAtkins> dbaron: So I'm a little skeptical of the "wait and see" suggestion.
<TabAtkins> dbaron: Think even if they don't do it a lot it's not a strong signal against.
<astearns> ack fantasai
<TabAtkins> fantasai: I think we should do this based only on color-scheme not on MQ.
<TabAtkins> fantasai: And on the color-scheme of the element originating the VT, consistently for the entire tree.
<TabAtkins> q+
<TabAtkins> fantasai: So I propose we add a new keyword to blending mode that does this
<fantasai> s/keyword/keyword (plus-auto)/
<emilio> TabAtkins: I disagree that we should do it on the element originating the transition
<astearns> +1
<emilio> ... as a benefit this could be implemented just with the light-dark() function we resolved a bit ago
<emilio> khush: what's that?
<emilio> TabAtkins: light-dark() returns one of two values if either is light or dark
<emilio> fantasai: that's a color
<emilio> TabAtkins: sure, light-dark-value() :)
<TabAtkins> khush: So say I have a funciton that picks one of these two values, what element does it come from?
<TabAtkins> khush: Here it would come from th epseudo-element, which inherits from the originating element.
<fantasai> mmmm that's not right at all
<TabAtkins> khush: But we can copy the color-scheme from the transitioning element to the pseudo and get it work correctly
<fantasai> that's correct
<TabAtkins> astearns: So proposed resolution is we copy the element's color-scheme to its ::view-transition-group
<TabAtkins> fremy: What happens if the initial page was light mode and next is dark mode?
<astearns> s/color-scheme/used color-scheme value/
<TabAtkins> khush: It takes the latest value, we ahve that with a lot of values already
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Copy the element's used color-scheme value to its ::view-transition-group
<TabAtkins> vmpstr: We also need to use this color-scheme to set the blend mode
<fantasai> mix-blend-mode: light-dark(plus-lighter, plus-darker)
<fantasai> s/light-dark/light-dark-value/
<fantasai> PROPOSED: mix-blend-mode on ::view-transition-group takes light-dark-value(plus-lighter, plus-darker)
<TabAtkins> proposed: ::view-transition-group uses plus-lighter or plus-darker, based on the color-scheme
<TabAtkins> (mechanism TBD)
<TabAtkins> RESOLVED: ::view-transition-group uses plus-lighter or plus-darker, based on the color-scheme (mechanism TBD)

[khushalsagar]

Resolutions have been added to the spec. Keeping the issue open since we still need to do : "::view-transition-group uses plus-lighter or plus-darker, based on the color-scheme (mechanism TBD)".