Bug 204541 – [CSS4 Pseudo] background-color of ::selection should be painted as specified

• Status: NEW
• Component: CSS

[Gérard Talbot (no longer involved)]

Test:
http://www.gtalbot.org/BrowserBugsSection/CSS4Pseudo/active-selection-012.html

Expected result:
http://www.gtalbot.org/BrowserBugsSection/CSS4Pseudo/active-selection-012-ref.html
Background-color should be green (#008000 or rgb(0, 128, 0))

Actual result in Epiphany Technological Preview 3.34.0-32-g514d1bfb6 (WebKitGTK 2.26.1)
Background-color is not green but rather #334C00 or rgb(51, 76, 0)

Firefox 68+ passes this test.

Spec states:
"
  *_For non-replaced content_*, the UA must honor the 
  color and background-color (including their alpha 
  channels) as specified. (...)
"
  coming from
  https://www.w3.org/TR/css-pseudo-4/#highlight-painting

Blink equivalent issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=1018450

I searched for a duplicate and did not find any.

[Radar WebKit Bug Importer]

<rdar://problem/57454724>

[Ahmad Saleem]

I am able to reproduce this bug in Safari 16.1 and Safari Technology Preview 156 where the background color is not matching with the reference "expected result" link while all other browsers (Chrome Canary 109 and Firefox Nightly 108) get expected results. Thanks!

[Gérard Talbot (no longer involved)]

Test:
http://wpt.live/css/css-pseudo/active-selection-012.html

Reference:
http://wpt.live/css/css-pseudo/reference/active-selection-012-ref.html

Browser results:
https://wpt.fyi/results/css/css-pseudo/active-selection-012.html?label=experimental&label=master&aligned&view=subtest

[Ana Tudor]

This continues to be an issue in 2026. Not just for `background-color`, but in some cases on iOS for `color` as well.

Here's a test case I made before I searched if such a bug was already filed https://codepen.io/thebabydino/pen/xbOByag?editors=0100

I could only test this via Epiphany, but I have asked on both Bluesky (https://bsky.app/profile/anatudor.bsky.social/post/3mes3gj4eg226) and Mastodon (https://mastodon.social/@anatudor/116066874519139462 and the replies confirm it happens in actual Safari too.

A couple of the iOS screenshots (this https://bsky.app/profile/aarontgrogg.com/post/3mesaanp46s2y and this https://mastodon.social/@burkybang/116067124766648179) are really worrying because not only is neither the `color`, nor the `background-color` respected there, but that is just terrible contrast, which was something I was seeking to avoid via the CSS I wrote, but that's just not being respected.

[Simon Fraser (smfr)]

I think this is because we're painting the selection with a blend mode.

[Ahmad Saleem]

Color RenderTheme::transformSelectionBackgroundColor(const Color& color, OptionSet<StyleColorOptions>) const
{
    return blendWithWhite(color);
}

&

Color RenderElement::selectionBackgroundColor() const
{
    if (style().usedUserSelect() == UserSelect::None)
        return Color();

    if (frame().selection().shouldShowBlockCursor() && frame().selection().isCaret())
        return theme().transformSelectionBackgroundColor(style().visitedDependentColorApplyingColorFilter(), styleColorOptions());

    auto pseudoStyleCandidate = this;
    if (pseudoStyleCandidate->isAnonymous())
        pseudoStyleCandidate = pseudoStyleCandidate->firstNonAnonymousAncestor();

    if (pseudoStyleCandidate) {
        auto pseudoStyle = pseudoStyleCandidate->selectionPseudoStyle();
        if (pseudoStyle && pseudoStyle->visitedDependentBackgroundColorApplyingColorFilter().isValid())
            return theme().transformSelectionBackgroundColor(pseudoStyle->visitedDependentBackgroundColorApplyingColorFilter(), styleColorOptions());
    }

    if (frame().selection().isFocusedAndActive())
        return theme().activeSelectionBackgroundColor(styleColorOptions());
    return theme().inactiveSelectionBackgroundColor(styleColorOptions());
}

Might be to explore here.