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. 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/14b839a7-3cdc-4536-ad14-c050177a4375n%40chromium.org.
