[css-pseudo-4] painting order of find-in-page highlights

[delan]

2. Where should they go in the highlight painting order? We propose that they paint over everything except maybe ::selection, because they reflect an explicit user intent to identify the search string, even more so than ::target-text (see also #4594).

3812 suggests adding new highlight pseudos for find-in-page search results, but does not specify the painting order.

We propose that find-in-page highlights paint on top of all existing highlights, for three reasons:

• painting them over ::target-text reflects an explicit user intent to identify the search string that is stronger than ::target-text (for ::target-text, you only need to click on a link)
• painting them over ::selection improves compat with current Firefox behaviour of eagerly moving the selection with the active match (see my comment in #3812; cc @emilio)
• painting them over ::selection improves compat with current Safari behaviour of painting the active match in a special topmost overlay (see my comment in #3812; cc @litherum, @smfr)

[smfr]

Agree that find highlights should paint on top of everything else. In WebKit/Safari, these are painted outside of the web content, in an overlay, with graphical effects that are not possible via web content.

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo-4] painting order of find-in-page highlights, and agreed to the following:

• RESOLVED: ::search-text paints directly above or directly below ::selection (up to UA)

The full IRC log of that discussion

<fantasai> schenney: if you implement this, and what order do you paint when there's overlap?
<fantasai> schenney: proposed that ::search-text paints on top of everything else, including ::selection
<fantasai> florian: I think I agree. Have we compared what existing implementations do?
<fantasai> florian: In Firefox you can't tell becaue ...
<fantasai> schenney: when find-in-page changes you switch from search to highlight
<fantasai> schenney: only relevant in chromium
<Rossen__> ack fantasai
<TabAtkins> fantasai: not true, Firefox let syous elect text while search text is highlighted
<TabAtkins> fantasai: Not the active search one, the current one is no longer current once you start interacting
<TabAtkins> fantasai: but you can highlight over found text, and selection highlights over that found text.
<TabAtkins> fantasai: and that makes sense
<fantasai> florian: In firefox selection text is semi-transparent blue text...
<fantasai> fantasai: you're on a Mac
<fantasai> florian: ::selection is on top and somewhat transparent
<fantasai> florian: if you switch focus from the window you will see the selection tainting the color of the search
<fantasai> fantasai: on Linux the selection is opaque, and very clearly on top
<fantasai> florian: would that work for Chrome?
<fantasai> schenney: we can go with anything
<TabAtkins> fantasai: if you had find-within-selection you might want the find on top, but i don't think anyone implements that
<fantasai> florian: if you select then search in Chrome, does the selection stop being there?
<fantasai> Rossen: seems the selection gets invalidated
<fantasai> florian: so if you have both then you selected most recently, then maybe it should be on top
<fantasai> Rossen: let's take a resolution, can always flip it if there's a different use case
<fantasai> florian: so search would be over everything except ::selection
<TabAtkins> fantasai: I think I'm okay with this, but might make sense to leave the ordering of the last two up to the UA, and simply say they must be on top
<TabAtkins> Rossen__: Isn't this the point of the issue tho?
<TabAtkins> fantasai: We're clarifying it's on top of everything *other than* selection
<dholbert> I think the proposal matches what I'm seeing on Firefox on Linux. (I see what fantasai described in some cases too, with the selections being opaque, but in some cases the selection does seem to be semitransparent and on-top (as florian noted)
<fantasai> schenney: leaves open possibility of active over selection and inactive underneath
<TabAtkins> schenney: Also allows the possibility of active search over selection, inactive under selection
<vmpstr> q+
<fantasai> [discussion of various highlight pseudos]
<fantasai> schenney: definitely over custom highlight
<fantasai> schenney: this also defines which color wins, and if author specifies it, that color should also win
<fantasai> schenney: not just background
<fantasai> vmpstr: clarify paint on top of everything, just within the element
<fantasai> PROPOSED: ::search-text paints directly above or directly below ::selection (up to UA)
<Rossen__> ack vmpstr
<fantasai> florian: agree above everything else, unsure if we shouldn't pin down more, but can start with this and maybe make stricter later on if necessary
<fantasai> Rossen: hearing no objections
<fantasai> RESOLVED: ::search-text paints directly above or directly below ::selection (up to UA)