[css-pseudo-4] Add highlight pseudo for in-page search

[frivoal]

::spelling-error and ::grammar-error allow authors to change the style of two browser-provided highlighting mechanisms.

Using the same system, it would be useful to have a pseudo to change the styling of the highlight shown by browsers when using in-page search. As browsers differentiate between the currently active search result, and other search results, we'd need two pseudos. Straw-man naming proposals:

• ::active-search
• ::inactive-search

Safari goes beyond just highlighting the range and also provides additional effects, including bouncy zooming effects when switching which element is focused, or an effect graying out the rest of the page. The proposal here does not try to account for these UI effects, which would continue to exist as desired by the browser.

---

Note: this is not covered by proposals discussed previously, such as the one from Microsoft, to enable authors to create their own custom stylable ranges via some kind of js api, since the point here is to style a browser-provided range, not an author provided-range.

[gibson042]

I find myself really wishing for this when interacting with the ECMAScript specification, which supports its own highlighting of variables in algorithms. For example, visit https://tc39.es/ecma262/multipage/notational-conventions.html#sec-returnifabrupt , click on the italicized argument to highlight all instances of that variable in the section, and then use the native browser find-in-page facility to search for "arg". On my machine, the styling for matching selections is almost completely indistinguishable from that of the page-provided highlights—in fact, the only difference I can discern is slight bolding of the former, although technically the background color is #ffff00 vs. #ffff33:

Since there is no standard for in-page match styling, there is no color that the custom functionality could use which would be guaranteed to not have this issue. So what's really missing here is a way for the page to set that styling along with the custom highlighting via something like the above-mentioned ::active-search and ::inactive-search.

[samuelbradshaw]

I would recommend ::active-match and ::inactive-match as names (using match instead of search).

[delan]

We are preparing an intent to prototype this in Chromium (cc @schenney-chromium, @jihyerish). Based on this issue and the discussion in #5233 and #5522, it seems there are a few things worth resolving:

1. Do we really need two highlight pseudos, or would a pseudo-class like ::search-match:active make more sense? Since ::active-search and ::inactive-search sound like they would be mutually exclusive, this may just be a question of elegance, not ambiguity like in [css-pseudo-4] ::selection vs ::inactive-selection #4579.

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 [css-pseudo] priority of the native highlights #4594).

3. What do we do about Firefox moving the selection with the active match? (cc @emilio) — Firefox and Safari eagerly move the selection to the active match (see demo). This is unlike Chrome, where the selection is cleared from when you first execute a search with new terms, to when you exit find-in-page. If search matches become highlight pseudos that paint below ::selection, the matches will look like selections, not matches.

   • We could make (active?) matches paint over ::selection rather than below it — Firefox can continue moving the selection with the active match, and this may be more compatible with Safari’s find-in-page overlay behaviour
   • We could make Firefox move the selection to the active match only when exiting find-in-page — this might be better for privacy anyway (see @zcorpan’s comment here)

4. What do we do about Safari’s yellow “bubbles”? (cc @litherum, @smfr) — Safari on macOS and iOS has special platform-specific appearance for find-in-page. They darken everything except the matches, which seems like it will be compatible with these new highlights, but their yellow “bubbles” for the active match paint on top of everything, can only have one background color, and may not be able to handle anything other than plain text, not even text decorations (see demo and screenshots below).

   • We could disable special appearance for find-in-page when a match (or the page) has custom styles — though I’m not too sure about the UI implications here (see comments by myles in #5233)
   • We could allow UAs to parse and compute but ignore find-in-page styles that they can’t support — Safari’s approach already ensures contrast with page colors, which so far seems to be the main use case anyway

[samuelbradshaw]

1. Do we really need two highlight pseudos…

1. **Do we really need two highlight pseudos, or would a pseudo-class like ::search-match:active make more sense?** Since ::active-search and ::inactive-search sound like they would be mutually exclusive, this may just be a question of elegance, not ambiguity like in [[css-pseudo-4] ::selection vs ::inactive-selection #4579](https://github.com//issues/4579).

I like the proposal of ::search-match and ::search-match:active (or maybe ::search-match:focus?) rather than adding two new pseudo-elements.

2. Where should they go… 3. What do we do about Firefox…

2. **Where should they go in the highlight [painting order](https://drafts.csswg.org/css-pseudo/#highlight-painting)?** 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 [[css-pseudo] priority of the native highlights #4594](https://github.com//issues/4594)).

3. What do we do about Firefox moving the selection with the active match? (cc @emilio) — Firefox and Safari eagerly move the selection to the active match (see demo). This is unlike Chrome, where the selection is cleared from when you first execute a search with new terms, to when you exit find-in-page. If search matches become highlight pseudos that paint below ::selection, the matches will look like selections, not matches.

   • We could make (active?) matches paint over ::selection rather than below it — Firefox can continue moving the selection with the active match, and this may be more compatible with Safari’s find-in-page overlay behaviour
   • We could make Firefox move the selection to the active match only when exiting find-in-page — this might be better for privacy anyway (see @zcorpan’s comment here)

I think it makes sense for the match to be painted above everything including the selection. Is there a downside to this? I tested in Safari, Chrome, and Firefox (on macOS) and in all three, selection isn't visible while in find-on-page mode. Given that, I don't think there'd ever be a case where you'd want a selection to appear on top of a search match.

4. What do we do about Safari’s…

4. **What do we do about Safari’s yellow “bubbles”? (cc @litherum, @smfr)** — Safari on macOS and iOS has special platform-specific appearance for find-in-page. They darken everything except the matches, which seems like it will be compatible with these new highlights, but their yellow “bubbles” for the active match [paint on top of everything](https://github.com//issues/5233#issuecomment-689678600), [can only have one background color](https://github.com//issues/5233#issuecomment-689678600), and may not be able to handle anything other than plain text, not even text decorations (see [demo](http://bucket.daz.cat/work/igalia/0/65.html) and screenshots below).

• We could disable special appearance for find-in-page when a match (or the page) has custom styles — though I’m not too sure about the UI implications here (see comments by myles in #5233)
• We could allow UAs to parse and compute but ignore find-in-page styles that they can’t support — Safari’s approach already ensures contrast with page colors, which so far seems to be the main use case anyway

This second option sounds similar in some ways to CSS accent-color: the author specifies a color, and the browser applies it to various elements that would normally have color. Which elements or parts of elements actually get the color varies between browsers.

What Safari's doing brings up another question, though – should authors also be able to style the dark backdrop? There is a ::backdrop pseudo-element – should that apply to find-on-page, in browsers that use a backdrop for find-on-page?

[delan]

Breaking out the two easier questions for the agenda: #10212 + #10213