Hi folks, I'm finally back to this. I just spent some time looking for further sources of developer and user needs for this feature.
One use-case I had not previously appreciated is in user-facing contrast adjustment for find-in-page results. With ::search-text an extension could provide functionality to adjust the colors. I've updated the chromestatus entry to add three more developer notes: - On the original CSS WG issue someone wants this to avoid conflicts with the ECMAScript spec highlights. https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181 - In a discussion about find-in-page and accessibility, a "remaining challenge is "Styling Search Matches" https://schepp.dev/posts/rethinking-find-in-page-accessibility-making-hidden-text-work-for-everyone/#remaining-challenges - A Mozilla user asks for the feature here: https://connect.mozilla.org/t5/ideas/increased-visibility-for-current-quot-find-in-page-quot-match/idi-p/26500 WIth this in mind I will re-request API owners approval. Cheers, Stephen. On Mon, Sep 29, 2025 at 2:10 PM Alex Russell <[email protected]> wrote: > Hey Stepen, > > Any progress? Again, inclined to LGTM, as the arguments we've heard from > other vendors to date are not compelling. If there's more to add, would be > great to get it in this thread. Would like to get you unblocked. > > Best, > > Alex > > On Monday, September 8, 2025 at 8:49:04 AM UTC-7 Stephen Chenney wrote: > >> 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. >> >> Cheers, >> Stephen. >> >> On Wed, Sep 3, 2025 at 10:09 AM Alex Russell <[email protected]> >> wrote: >> >>> 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 >>> >>> On Wednesday, August 27, 2025 at 11:07:10 PM UTC+1 [email protected] >>> wrote: >>> >>>> 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 >>>> >>>> On Friday, August 15, 2025 at 5:45:19 AM UTC-7 Stephen Chenney wrote: >>>> >>>>> 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 < >>>>> [email protected]> 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 >>>>>> <https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md#-motivation> >>>>>> of >>>>>> the explainer, 3 StackOverflow links were given: >>>>>> >>>>>> - Someone directly asks for CSS styling of find-in-page >>>>>> >>>>>> <https://stackoverflow.com/questions/50309703/css-for-browsers-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 >>>>>> >>>>>> <https://stackoverflow.com/questions/18666075/how-to-style-detect-highlighted-boxes-generated-from-browser-native-search-in-pa>: >>>>>> it's not clear why the developer wants to do this. >>>>>> - A user wants to hide find-in-page results >>>>>> >>>>>> <https://stackoverflow.com/questions/77458310/confuse-browsers-in-built-find-in-page-feature>: >>>>>> 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 >>>>>> <https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181> >>>>>> 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. >>>>> >>>>> >>>>>> -- Dan >>>>>> >>>>>> On Wednesday, July 16, 2025 at 12:41:48 PM UTC-7 Stephen Chenney >>>>>> wrote: >>>>>> >>>>>>> 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. >>>>>>> >>>>>>> On Wed, Jul 16, 2025 at 11:14 AM Philip Jägenstedt < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> On testing in WPT, can you look into a WebDriver BiDi command for >>>>>>>> triggering find-in-page? That would enable testing this. >>>>>>>> >>>>>>>> On Wed, Jul 16, 2025 at 5:11 PM Philip Jägenstedt < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> 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 :) >>>>>>>>> >>>>>>>>> On Mon, Jul 14, 2025 at 1:43 PM Stephen Chenney < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> On Sun, Jul 13, 2025 at 11:58 PM Domenic Denicola < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thursday, July 10, 2025 at 4:41:12 AM UTC+9 Chromestatus >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Contact emails [email protected], [email protected] >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> >>>>>>>>>>> >>>>>>>>>>> Search tags search <http:///features#tags:search> >>>>>>>>>>> >>>>>>>>>>> TAG review None >>>>>>>>>>> >>>>>>>>>>> TAG review status Not applicable >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Can you explain why it is not applicable? I can't see which >>>>>>>>>>> exception >>>>>>>>>>> <https://www.chromium.org/blink/launching-features/wide-review/#exceptions> >>>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>> ? 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 >>>>>>>>>>> <https://chromestatus.com>. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> 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 [email protected]. >>>>>>>>>> To view this discussion visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzRDTpo0grPCaqQkdUOacQQ0ovjr_mL-%3DpOmxYKqcyNYMw%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzRDTpo0grPCaqQkdUOacQQ0ovjr_mL-%3DpOmxYKqcyNYMw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>>>> 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 [email protected]. >>>>>> >>>>> To view this discussion visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/df61d4d1-f902-46ef-9e6d-ad349f7c556bn%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/df61d4d1-f902-46ef-9e6d-ad349f7c556bn%40chromium.org?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzT8TPf8dPQXzSUM_ueX%2B1wvhHFfo%2B6fv2cPtUaydeNJwg%40mail.gmail.com.
