Re: [csswg-drafts] [css-pseudo-4] painting order of find-in-page highlights (#10213)

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)`

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10213#issuecomment-2089311110 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 2 May 2024 00:00:36 UTC