[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 #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 #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/w3c/csswg-drafts/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/w3c/csswg-drafts/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/w3c/csswg-drafts/issues/5233#issuecomment-689678600), [can only have one background color](https://github.com/w3c/csswg-drafts/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

[aardrian]

What system color keywords will be assigned? I am assuming Highlight and HighlightText.

For context, § 3.3. Default UA Styles defines text-decoration-line for ::spelling-error and ::grammar-error. But highlighted text is mapped to background and foreground colors:

Some highlight pseudo-elements should have paired default highlight colors—a default color and background-color provided by the UA that are either used or overridden together, see § 3.3.1 Paired Defaults. For ::selection they should correspond to HighlightText and Highlight, while for ::target-text they should correspond to MarkText and Mark.

I could not find this in the related issues, so apologies if my search-fu was terrible.

[delan]

What system color keywords will be assigned? I am assuming Highlight and HighlightText.

Split out to another issue: #10329

[josepharhar]

Presumably this is telling the page information about what the user has typed into the find-in-page box which may be a privacy concern, but hopefully we can use the same justification that I used for hidden=until-found and auto-expanding <details>: https://github.com/WICG/display-locking/blob/main/privacy-assessments/auto-expanding-details-privacy.md#2-what-privacy-attacks-have-been-deemed-out-of-scope-and-why

Edit: it sounds like this feature might actually not reveal anything about find-in-page, in which case this is no problem - I'd have to mess around with an implementation to find out.

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo-4] Add highlight pseudo for in-page search.

The full IRC log of that discussion

<fantasai> schenney: Use cases for modifying the colors for find-in-page results on platforms that use colors
<fantasai> schenney: wouldn't apply in Safari's case
<fantasai> schenney: but both FF and Chromium browsers basically put a highlight the text
<fantasai> schenney: and some authors want to tweak colors to avoid conflicts or improve contrast
<fantasai> schenney: We prototyped, now want to ask if anyone has comments
<fantasai> emilio: we do implement this as a non-exposed system color so seems ok
<fantasai> emilio: they're hard-coded, so doesn't expose system colors
<fantasai> schenney: Page has no idea of what's actually highlighted
<fantasai> schenney: So don't think there are any new privacy issues here.
<astearns> fantasai: the main thing to worry about is if the author chooses intentionally-obscurre colors
<fserb> annevk, I see. Could we set up a "WHATWG subgroup to discuss canvas text"? Would that work?
<fantasai> schenney: There are people trying to prevent people from searching, e.g. suggestion to capture Ctrl+F
<fantasai> schenney: similar problem for selection and grammar-error
<fserb> annevk if we could have someone to participate at that from Apple, that would work.
<fantasai> schenney: If no other comments, then will go forward with previosu resolution.

[schenney-chromium]

Presumably this is telling the page information about what the user has typed into the find-in-page box which may be a privacy concern, but hopefully we can use the same justification that I used for hidden=until-found and auto-expanding <details>: https://github.com/WICG/display-locking/blob/main/privacy-assessments/auto-expanding-details-privacy.md#2-what-privacy-attacks-have-been-deemed-out-of-scope-and-why

Edit: it sounds like this feature might actually not reveal anything about find-in-page, in which case this is no problem - I'd have to mess around with an implementation to find out.

This feature would behave the same as ::spelling-error, ::grammer-error and other styling that may reveal user's dictionaries or other private information. A page can see how a search result would be styled if it were a search result, but has no way of knowing whether an element is currently rendered using the style.

[jihyerish]

I'm closing this issue since the spec is updated

• https://drafts.csswg.org/css-pseudo-4/#selectordef-search-text

by https://github.com/w3c/csswg-drafts/pull/10475