LGTM2 On testing, I see that the key piece is internals.addTextMatchMarker here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/css/support/markers.js;l=29-36;drc=f3fae8c3c1c805156cf7a5a8124db274bdd7c355
Defining a WebDriver BiDi command for this is probably straightforward, although I'm not aware of CSS specs defining WebDriver BiDi commands in the style of https://w3c.github.io/webauthn/#sctn-automation. If you'd like to do this it would be great, but I also think it's OK to just file an issue at https://github.com/web-platform-tests/wpt/issues?q=is%3Aissue%20state%3Aopen%20label%3Atype%3Auntestable and do it if there's a second feature that needs it, or a second implementer that requests it. On Wed, Nov 19, 2025 at 5:10 PM Mike Taylor <[email protected]> wrote: > LGTM1 > On 11/17/25 2:54 p.m., Stephen Chenney wrote: > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzT8TPf8dPQXzSUM_ueX%2B1wvhHFfo%2B6fv2cPtUaydeNJwg%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/CAARdPYdKtGgVuaAd7B5RT1Zm8WGp_Qz9hyKqO-Y-wdoHaOHS5A%40mail.gmail.com.
