Re: [blink-dev] Intent to Ship: Do not invert selection background color when it matches text color
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?id=1217745
>
>
> **Link to entry on the Chrome Platform Status**
> https://chromestatus.com/feature/5657973985640448
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+unsubscr...@chromium.org
> .
> To view this discussion on the web visit
>
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d48df17c-160c-4b98-c77c-41f063891570%40igalia.com
>
> .
>
> --
Re: [blink-dev] Intent to Ship: Do not invert selection background color when it matches text color
Do we know the reasons why WebKit changed behavior?
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?id=1217745
>
> **Link to entry on the Chrome Platform Status**
> https://chromestatus.com/feature/5657973985640448
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d48df17c-160c-4b98-c77c-41f063891570%40igalia.com
> .
>
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUYwsGphd1%3DcimqSzS3SrfFeCHc0HaHbGRxqy5Kj5t25A%40mail.gmail.com.
[blink-dev] Intent to Ship: Do not invert selection background color when it matches text color
**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?id=1217745
**Link to entry on the Chrome Platform Status**
https://chromestatus.com/feature/5657973985640448
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d48df17c-160c-4b98-c77c-41f063891570%40igalia.com.
