Re: [blink-dev] Intent to Ship: Do not invert author selection background color when it matches text color

[Manuel Rego Casasnovas]

Hi Stephen,

I think it'd be nice to send a new intent-to-ship and update the 
chromestatus entry with the new agreed behavior on CSSWG (I've made you 
an owner of https://chromestatus.com/guide/edit/5657973985640448). As 
this a quite old one and the template and process has changed a lot 
since then.


Thanks,
  Rego

On 22/02/2024 19:55, Stephen Chenney wrote:
It's been a while but it's time to revive this intent to respect author 
provided colors in ::selection rather than inverting the background when 
it matches the foreground. This makes chromium compatible with other 
engines.


The CSS Working group resolved issue 6150 
 to require that 
browsers respect the author supplied colors in ::selection pseudos. This 
resolution has no impact on the browser's default selection behavior.


CL 5314122 
 
implements the change.


Any objections?

In implementing this I discovered that in the default case (of no 
::selection pseudo at all) we would only have problems in inactive 
windows on Linux. In other cases there is transparency so even if you 
have matching colors in the foreground and background there remains some 
contrast due to opacity blending.


Stephen.

On Tuesday, October 5, 2021 at 6:02:10 AM UTC-4 Manuel Rego wrote:


On 04/10/2021 14:24, Yoav Weiss wrote:
 > Do we know the reasons why WebKit changed behavior?

Thanks for the question Yoav. This question lead to further
investigation to find out this is a total mess, so I abandon this
intent
for now. Maybe in the future we could resend this.

For more details you can check this CSSWG issue (just found it today):
https://github.com/w3c/csswg-drafts/issues/6150


WebKit still changes the background color, but not in the same
situations than Chromium:
* Chromium inverts it here:
::selection { color: lime; background: lime; }
* While WebKit does this here:
::selection { color: rgba(0, 255, 0, .8); background: lime; }
Because WebKit modifies the background set by the user to add 80%
opacity to it.

This code comes from an older commit than the one I pointed in the
intent: https://trac.webkit.org/changeset/1447/webkit
 (19 years ago).

And there was a funny comment on WebKit source code 17 years ago
(https://trac.webkit.org/changeset/7766/webkit
):
// If the text color ends up being the same as the selection
// background, invert the selection background. This should
// basically never happen, since the selection has transparency.

Like this only happens if the text color also has such transparency.

Anyway, we'll add this information on the CSSWG issue and see if
there's
any kind of agreement.

So ignore this intent for now.

Cheers,
Rego

 > On Mon, Oct 4, 2021 at 1:34 PM Manuel Rego Casasnovas
mailto:r...@igalia.com>
 > >> wrote:
 >
 >
 > **Contact emails**
 > r...@igalia.com  >, dazab...@igalia.com

 > >
 >
 > **Specification**
 > https://www.w3.org/TR/css-pseudo-4/#selectordef-selection

 > >
 >
 > **Summary**
 >
 > Right now selection background color is inverted when it matches the
 > text color in Chromium.
 > So if you have a rule like this "::selection { color: cyan;
background:
 > cyan; }" the background gets inverted and a red background color is
 > used.
 > This is an old behavior inherited from WebKit but Safari doesn't
do this
 > anymore (and Firefox has never done this).
 > The proposal is to stop inverting the background color for
::selection.
 >
 > **Blink component**
 > Blink>CSS
 >
 > **TAG review**
 > N/A
 >
 > This is mostly a bug fix but we're sending the intent as a PSA
and due
 > to the potential compat risk.
 >
 > **Risks**
 >
 > **Interoperability and Compatibility**
 >
 > The current Chromium behavior comes from WebKit
 > (trac.webkit.org/changeset/52548/webkit

 > >).
 > WebKit has changed this behavior in the past and is no longer doing
 > this.
 > Firefox has never done this.
 > This will align Chromium with t

Re: [blink-dev] Intent to Ship: Do not invert author selection background color when it matches text color

[Stephen Chenney]

It's been a while but it's time to revive this intent to respect author 
provided colors in ::selection rather than inverting the background when it 
matches the foreground. This makes chromium compatible with other engines.

The CSS Working group resolved issue 6150 
 to require that browsers 
respect the author supplied colors in ::selection pseudos. This resolution 
has no impact on the browser's default selection behavior.

CL 5314122 
 
implements the change.

Any objections?

In implementing this I discovered that in the default case (of no 
::selection pseudo at all) we would only have problems in inactive windows 
on Linux. In other cases there is transparency so even if you have matching 
colors in the foreground and background there remains some contrast due to 
opacity blending.

Stephen.

On Tuesday, October 5, 2021 at 6:02:10 AM UTC-4 Manuel Rego wrote:


On 04/10/2021 14:24, Yoav Weiss wrote: 
> Do we know the reasons why WebKit changed behavior? 

Thanks for the question Yoav. This question lead to further 
investigation to find out this is a total mess, so I abandon this intent 
for now. Maybe in the future we could resend this. 

For more details you can check this CSSWG issue (just found it today): 
https://github.com/w3c/csswg-drafts/issues/6150 

WebKit still changes the background color, but not in the same 
situations than Chromium: 
* Chromium inverts it here: 
::selection { color: lime; background: lime; } 
* While WebKit does this here: 
::selection { color: rgba(0, 255, 0, .8); background: lime; } 
Because WebKit modifies the background set by the user to add 80% 
opacity to it. 

This code comes from an older commit than the one I pointed in the 
intent: https://trac.webkit.org/changeset/1447/webkit (19 years ago). 

And there was a funny comment on WebKit source code 17 years ago 
(https://trac.webkit.org/changeset/7766/webkit): 
// If the text color ends up being the same as the selection 
// background, invert the selection background. This should 
// basically never happen, since the selection has transparency. 

Like this only happens if the text color also has such transparency. 

Anyway, we'll add this information on the CSSWG issue and see if there's 
any kind of agreement. 

So ignore this intent for now. 

Cheers, 
Rego 

> On Mon, Oct 4, 2021 at 1:34 PM Manuel Rego Casasnovas  > wrote: 
> 
> 
> **Contact emails** 
> r...@igalia.com , dazab...@igalia.com 
>  
> 
> **Specification** 
> https://www.w3.org/TR/css-pseudo-4/#selectordef-selection 
>  
> 
> **Summary** 
> 
> Right now selection background color is inverted when it matches the 
> text color in Chromium. 
> So if you have a rule like this "::selection { color: cyan; background: 
> cyan; }" the background gets inverted and a red background color is 
> used. 
> This is an old behavior inherited from WebKit but Safari doesn't do this 
> anymore (and Firefox has never done this). 
> The proposal is to stop inverting the background color for ::selection. 
> 
> **Blink component** 
> Blink>CSS 
> 
> **TAG review** 
> N/A 
> 
> This is mostly a bug fix but we're sending the intent as a PSA and due 
> to the potential compat risk. 
> 
> **Risks** 
> 
> **Interoperability and Compatibility** 
> 
> The current Chromium behavior comes from WebKit 
> (trac.webkit.org/changeset/52548/webkit 
> ). 
> WebKit has changed this behavior in the past and is no longer doing 
> this. 
> Firefox has never done this. 
> This will align Chromium with the other browsers. 
> 
> Use counter was added in M93 and it's around 0.0003% 
> (https://chromestatus.com/metrics/feature/timeline/popularity/3934 
> ). 
> This change might make selected content impossible to read in some web 
> pages (but that's already happening in Safari and Firefox). 
> Or maybe this is making some webpages work as expected, if they were 
> using selection colors to hide some content. 
> 
> Gecko: Shipped/Shipping 
> 
> WebKit: Shipped/Shipping 
> 
> Web developers: No signals. This is mostly a bug fix, removing a quirk 
> to improve interop; so it doesn't look like we need to ask for specific 
> web developer signals. 
> 
> **Is this feature fully tested by web-platform-tests?** 
> 
> We're adding a new test specifically verifying this behavior in 
> https://chromium-review.googlesource.com/c/chromium/src/+/3199752 
> . 
> 
> Apart from that css/css-pseudo/active-selection-018.html fails partially 
> due to this issue if you enable HighlightInheritance runtime flag. 
> 
> **Tracking bug** 
> https://bugs.chromium.org/p/chromium/issues/detail