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/7a6a38db-10c6-4bfe-8ce0-54b4596d0176n%40chromium.org.
