[css-pseudo] allowing ::search-text:current its own overlay

[delan]

#10212 resolved that ::search-text (#3812) will be a single highlight pseudo with two states, which currently implies a single highlight overlay (css-pseudo #highlight-bounds).

But while working on the ::search-text paint impl in Chromium, we found that splitting :current and :not(:current) into separate highlight overlays for paint makes the impl a lot less complicated. With a single overlay, the highlight overlay code needs to explicitly track where ::search-text was :current, so we can store and switch between two sets of computed and resolved styles for ::search-text (and ::selection). With two overlays, it’s all encoded in which overlay we choose.

We propose allowing impls to paint ::search-text:current and ::search-text:not(:current) in separate highlight overlays. This would have minor painting order side effects, like backgrounds of :current overlapping text shadows of :not(:current), but the rendering would otherwise be roughly the same.

If this proposal is considered infeasible, one alternative would be to reverse our resolution in #10212 and split ::search-text back into two highlight pseudos.

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo] allowing ::search-text:current its own overlay, and agreed to the following:

• RESOLVED: Give ::search-text:current its own overlay

The full IRC log of that discussion

<kbabbitt> schenney: for context, there's a notion of highlight overlays that have a stacking order
<kbabbitt> ... overlay with defined order on overlays
<kbabbitt> ... pseudo for search text where you specify search text current which is currently active find in page instance
<kbabbitt> ... just search text is the inactive ones
<kbabbitt> ... this question is whether currently active one and active ones should have spearate highlight overlays
<kbabbitt> .. with current active on top of active in paint order
<kbabbitt> ... makes it easier to implement
<kbabbitt> ... change spec to say that search text current is one overlay, search text is another
<kbabbitt> ... define order as current over regular
<kbabbitt> florian: search-text includes current?
<kbabbitt> schenney: in principle they're mutually exclusive states
<kbabbitt> ... can't be both active and inactive
<kbabbitt> ... in practice ordering doesn't come up
<kbabbitt> florian: not one is superset of other, they're mutually exclusive?
<kbabbitt> schenney: yes
<kbabbitt> astearns: questions or concerns?
<kbabbitt> Proposed: Give search-text-current its own overlay
<kbabbitt> RESOLVED: Give ::search-text:current its own overlay
<kbabbitt> fantasai: if it's its own overlay, are we in same situation as :hover?
<kbabbitt> ... where we have multiple things and we're selecting one?
<kbabbitt> schenney: no
<kbabbitt> ... if you type multiple words into find in page, all words will match search-text-current
<kbabbitt> ... and get current highlighting
<kbabbitt> ....everything else will get search-text
<kbabbitt> florian: the interaction between this and hover
<kbabbitt> ... would we want it to be possible to do some effect when hovering search texty
<kbabbitt> ... vs hovering current search text
<kbabbitt> ... then it would need to be a subset
<kbabbitt> ... not sure it's a real use case but if it is we need to work it out
<kbabbitt> schenney: would work it out as part of hover
<kbabbitt> florian: we can only work it out as part of hover if ...
<kbabbitt> .... you just said they're mutually exclusive rather than a subset
<kbabbitt> ...
<kbabbitt> ... that seems to be incompatible with wanting to be able to highlight all search text when you hover current one
<kbabbitt> schenney: yes
<kbabbitt> florian: current one would also need to be part of everything else
<kbabbitt> ... so when you highlight one chunk, change the style of everything
<kbabbitt> ... not sure it's a real thing people want to do but defining them as mut ex makes it impossible to do
<kbabbitt> schenney: we've already defined them as mut ex so we'd ahve to revisit
<kbabbitt> ... but I see what you're saying
<kbabbitt> ... will open another issue for this
<kbabbitt> ... plan to open a bunch of issues related to hover
<kbabbitt> ... I'll make sure that gets addressed as part of hover stuff