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 <jyass...@google.com> if the TAG can expedite this, it would be great :)
On Mon, Jul 14, 2025 at 1:43 PM Stephen Chenney <schen...@chromium.org> wrote: > On Sun, Jul 13, 2025 at 11:58 PM Domenic Denicola <dome...@chromium.org> > wrote: > >> >> >> On Thursday, July 10, 2025 at 4:41:12 AM UTC+9 Chromestatus wrote: >> >> Contact emails schen...@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+unsubscr...@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/CAARdPYfChJeC%2B8vqscBJ%2BvZ8%3Dwh4EZ2ZHYQsCNy4tRRNzGX2mQ%40mail.gmail.com.
