Intent to Ship: CSS find-in-page highlight pseudos

Chromestatus

unread,

Jul 9, 2025, 3:41:12 PM Jul 9

to blin...@chromium.org, ji...@igalia.com, sche...@chromium.org

Summary

Exposes find-in-page search result styling to authors as a highlight pseudo-element, like selection and spelling errors. This allows authors to change the foreground and background colors or add text decorations, which can be especially useful if the UA defaults have insufficient contrast with the page colors or are otherwise unsuitable.

Blink component

Blink>CSS

Search tags

search

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The feature is in the CSS Pseudo spec and there are no open issues. The behavior is designed to be implementable in Firefox and Chrome, but is unlikely to be viable in Safari due to highly customize UI for find-in-page. The spec is explicit that browsers may choose not to implement this feature provided @supports information is correct. The Safari behavior is so different that developers are unlikely to believe their styling would apply there.

Gecko : Under consideration ( https://github.com/mozilla/standards-positions/issues/1103 )

WebKit : No signal ( https://github.com/WebKit/standards-positions/issues/421 ) Will file a request for position, but in spec conversations were neutral with no expectation of implementing it themselves.

Web developers : Positive Developers wishing to avoid conflicts with the find-in-page colors and their page styles have requested this feature. Someone directly asks for CSS styling of find-in-page: https://stackoverflow.com/questions/50309703/css-for-browsers-find-in-page Another direct question: https://stackoverflow.com/questions/18666075/how-to-style-detect-highlighted-boxes-generated-from-browser-native-search-in-pa A developer wants to hide find-in-page results: https://stackoverflow.com/questions/77458310/confuse-browsers-in-built-find-in-page-feature ) and could do so by styling them as transparent

Other signals :

Ergonomics

None.

Activation

There is no way to polyfill this. There is no real challenge to adopting beyond awareness that the feature exists, and we will be producing blog postings and other social media evangelization.

Security

There is no security risk. The CSS styling is available regardless of whether the text is search for or not, so user find-in-page queries cannot be seen by script.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No

Debuggability

There is no security risk. The CSS styling is available regardless of whether the text is search for or not, so user find-in-page queries cannot be seen by script.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

All platforms support find-in-page and could use CSS styling to improve legibility on some sites.

Is this feature fully tested by web-platform-tests ?

No

Testing is in wpt_internal tests due to a lack of wpt support for adding find-in-page markers. third_party/blink/web_tests/wpt_internal/css/css-pseudo/search-text-*

DevTrial instructions

https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md

Flag name on about://flags

Experimental Web Platform Features

Finch feature name

SearchTextHighlightPseudo

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/339298411

Measurement

We will implement UseCounters for this pseudo element (and all the other too, see https://issues.chromium.org/issues/381093928 )

Availability expectation

Available in Chrome, and Firefox. Not available in Safari

Adoption expectation

Hard to predict and not relevant to most sites

Adoption plan

Blog posts and developer outreach

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No

Estimated milestones

Shipping on desktop	140
DevTrial on desktop	135
Shipping on Android	140
DevTrial on Android	135
Shipping on WebView	140

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5195073796177920?gate=5047118541881344

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c447ed4dfd05b588e2afc650277371fd%40igalia.com

This intent message was generated by Chrome Platform Status .

Domenic Denicola

unread,

Jul 13, 2025, 11:58:33 PM Jul 13

to blink-dev, Chromestatus, ji...@igalia.com, Stephen Chenney

On Thursday, July 10, 2025 at 4:41:12 AM UTC+9 Chromestatus wrote:

Contact emails sche...@chromium.org , ji...@igalia.com

Explainer https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md

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

Design docs
https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md

Summary
Exposes find-in-page search result styling to authors as a highlight pseudo-element, like selection and spelling errors. This allows authors to change the foreground and background colors or add text decorations, which can be especially useful if the UA defaults have insufficient contrast with the page colors or are otherwise unsuitable.

Blink component Blink>CSS

Search tags search

TAG review None

TAG review status Not applicable

Can you explain why it is not applicable? I can't see which exception category it might fall into.

Stephen Chenney

unread,

Jul 14, 2025, 7:43:18 AM Jul 14

to Domenic Denicola, blink-dev, Chromestatus, ji...@igalia.com

On Sun, Jul 13, 2025 at 11:58 PM Domenic Denicola < dom...@chromium.org > wrote:

On Thursday, July 10, 2025 at 4:41:12 AM UTC+9 Chromestatus wrote:

Contact emails sche...@chromium.org , ji...@igalia.com

Explainer https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md

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

Design docs
https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md

Summary
Exposes find-in-page search result styling to authors as a highlight pseudo-element, like selection and spelling errors. This allows authors to change the foreground and background colors or add text decorations, which can be especially useful if the UA defaults have insufficient contrast with the page colors or are otherwise unsuitable.

Blink component Blink>CSS

Search tags search

TAG review None

TAG review status Not applicable

Can you explain why it is not applicable? I can't see which exception category it might fall into.

We weren't sure because this is a feature already in the CSS spec. I'll set up a review now, and I'll also look into the reviews for all the other highlights (spelling. grammar, find-in-page etc) to see if there's anything still actionable there.

Philip Jägenstedt

unread,

Jul 16, 2025, 11:12:01 AM Jul 16

to Stephen Chenney, Jeffrey Yasskin, Domenic Denicola, blink-dev, Chromestatus, ji...@igalia.com

Thank you for filing https://github.com/w3ctag/design-reviews/issues/1120 ! Since it was just two days ago, let's give it some time before proceeding. +Jeffrey Yasskin if the TAG can expedite this, it would be great :)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org .
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzRDTpo0grPCaqQkdUOacQQ0ovjr_mL-%3DpOmxYKqcyNYMw%40mail.gmail.com .

Philip Jägenstedt

unread,

Jul 16, 2025, 11:14:35 AM Jul 16

to Stephen Chenney, Jeffrey Yasskin, Domenic Denicola, blink-dev, Chromestatus, ji...@igalia.com

On testing in WPT, can you look into a WebDriver BiDi command for triggering find-in-page? That would enable testing this.

Stephen Chenney

unread,

Jul 16, 2025, 3:41:48 PM Jul 16

to Philip Jägenstedt, Jeffrey Yasskin, Domenic Denicola, blink-dev, Chromestatus, ji...@igalia.com

There's no problem waiting. We're not in any big hurry and we slowed ourselves down anyway.

Regarding WPT testing there's already https://github.com/web-platform-tests/wpt/issues/45844 to get this done and we should solve the spelling/grammar issue too, https://github.com/web-platform-tests/wpt/issues/30863 . I'll ask around and see if anyone at Igalia has bandwidth to do this.

Cheers,

Stephen.

Dan Clark

unread,

Jul 23, 2025, 12:05:01 PM Jul 23

to blink-dev, Stephen Chenney, Jeffrey Yasskin, dom...@chromium.org, blink-dev, Chromestatus, ji...@igalia.com, Philip Jägenstedt

The API Owners discussed this today and had some concerns that the motivation is not as clear as it could be. We'd like to better understand the developer need for styling these highlights.

Looking at the Motivation section of the explainer, 3 StackOverflow links were given:

Someone directly asks for CSS styling of find-in-page : the use case is "if a user use's their browser's find function to search through the table, the browser will highlight the matching text, but I want to be able to highlight the entire row if any of it's cells contain a match". But this proposal won't solve for this; it only allows for things like the color/background color to be changed, not the area that the highlight covers.
Another direct question : it's not clear why the developer wants to do this.
A user wants to hide find-in-page results : for this one the developer basically wants to disable find-on-page, which seems like something we don't want to be helping with since it makes things less accessible for users.

So these don't make a strong case to why this feature is the right answer.

If the main developer concern being solved for is lack of contrast for find results against other page content, such as in https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181 , then couldn't browsers be doing a better job of solving this problem by default rather than pushing the burden onto developers? For example, the case pointed out in that issue comment is not so bad in Safari because of Safari's greying-out of the rest of the page when Find is active.

-- Dan

Stephen Chenney

unread,

Aug 15, 2025, 8:45:19 AM Aug 15

to Dan Clark, blink-dev, Jeffrey Yasskin, dom...@chromium.org, Chromestatus, ji...@igalia.com, Philip Jägenstedt

Sorry for the time out. I'm still waiting for feedback from the developers who requested this, but I'll try to add some responses now.

On Wed, Jul 23, 2025 at 12:05 PM 'Dan Clark' via blink-dev < blin...@chromium.org > wrote:

The API Owners discussed this today and had some concerns that the motivation is not as clear as it could be. We'd like to better understand the developer need for styling these highlights.

We have TAG review now, https://github.com/w3ctag/design-reviews/issues/1120 , and the use case seems strong to them. They had questions about Safari compat.

Looking at the Motivation section of the explainer, 3 StackOverflow links were given:

Someone directly asks for CSS styling of find-in-page : the use case is "if a user use's their browser's find function to search through the table, the browser will highlight the matching text, but I want to be able to highlight the entire row if any of it's cells contain a match". But this proposal won't solve for this; it only allows for things like the color/background color to be changed, not the area that the highlight covers.

Another direct question : it's not clear why the developer wants to do this.

A user wants to hide find-in-page results : for this one the developer basically wants to disable find-on-page, which seems like something we don't want to be helping with since it makes things less accessible for users.

Yes, we don't know why the 2nd link wants styling. Regarding the last, developers can already capture the Ctrl-F and disable find in page, and as far as I can tell the way to get custom search styling is to implement the entire find-in-page system yourself. That's not a developer friendly solution.

So these don't make a strong case to why this feature is the right answer.

If the main developer concern being solved for is lack of contrast for find results against other page content, such as in https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181 , then couldn't browsers be doing a better job of solving this problem by default rather than pushing the burden onto developers? For example, the case pointed out in that issue comment is not so bad in Safari because of Safari's greying-out of the rest of the page when Find is active.

Our request comes from an embedder. They can apply downstream patches themselves to adjust styling, but it is cumbersome and gets more complicated when different styling is needed for different elements. Then they are implementing this entire feature themselves. The embedder story would get more complex, I think, if the browser layer took over find-in-page, as Safari seems to do. It's also worth pointing out that a browser level solution takes away power from the site. If an author doesn't like what Safari is doing, they cannot do anything about it beyond a complete custom search function. This raises the difficulty for those just wishing to improve the search results styling on their page.

I'll reply some more once I get more feedback from developers.

Stephen.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/df61d4d1-f902-46ef-9e6d-ad349f7c556bn%40chromium.org .

Dan Clark

unread,

Aug 27, 2025, 6:07:10 PM Aug 27

to blink-dev, Stephen Chenney, blink-dev, Jeffrey Yasskin, dom...@chromium.org, Chromestatus, ji...@igalia.com, Philip Jägenstedt, Dan Clark

Thanks Stephen for providing more context here. Please do let us know if you're able to get more developer feedback on this.

The way I'm looking at it, there's an important distinction between possible reasons developers might want the feature. If most only want it because the color schemes of their sites happen to have poor contrast with browsers' built-in find-in-page colors, that's a sign that maybe browsers should take care of ensuring contrast so developers don't have to think about this a11y problem. On the other hand, if developers want to control the find-in-page colors because they want to make them fit in stylistically with their page's color scheme, then that's clearly demonstrating need for this feature.

Interestingly, selection color is kind of an example in both directions. If devs don't do anything with it, browsers ensure contrast automatically, but authors can still control the colors if they want.

-- Dan

Alex Russell

unread,

Sep 3, 2025, 10:09:14 AM (8 days ago) Sep 3

to blink-dev, dan...@microsoft.com, Stephen Chenney, blink-dev, Jeffrey Yasskin, Domenic Denicola, Chromestatus, ji...@igalia.com, Philip Jägenstedt

Any updates here?

I'm inclined to LGTM this, but would feel much better about it if we had input from developers directly.

Best,

Alex

Stephen Chenney

unread,

Sep 8, 2025, 11:49:04 AM (3 days ago) Sep 8

to Alex Russell, blink-dev, dan...@microsoft.com, Jeffrey Yasskin, Domenic Denicola, Chromestatus, ji...@igalia.com, Philip Jägenstedt

There's quite a bit of discussion going on in the TAG and I'm (still) waiting on feedback from the client who requested this as to their specific use case. My goal is to improve our understanding of the motivation because right now it's unclear how to balance the benefits vs the risks of the feature. I have a meeting later this week to try to move things forward. Sorry for the delay.