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 <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. 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. -- 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 <foo...@chromium.org> > 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 <foo...@chromium.org> >> 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 <sche...@chromium.org> >>> wrote: >>> >>>> 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 >>>>> <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 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 >>>> >>>> <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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/df61d4d1-f902-46ef-9e6d-ad349f7c556bn%40chromium.org.
