Ready for Developer Testing: CSS find-in-page highlight pseudos
Chromestatus
Contact emails
sche...@chromium.org, daza...@igalia.comExplainer
https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.mdSpecification
https://drafts.csswg.org/css-pseudo-4/#selectordef-search-textDesign docs
https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md
Summary
Exposes find-in-page search results to authors as a highlight pseudo-element, like selections 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>CSSSearch tags
searchTAG review
NoneTAG review status
PendingRisks
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 Need to file request for comment.
WebKit: No signal 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?
None
Goals for experimentation
Ongoing technical constraints
None
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)?
YesAll 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?
NoTesting 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.mdFlag name on about://flags
Experimental Web Platform FeaturesFinch feature name
SearchTextHighlightPseudoRequires code in //chrome?
FalseTracking bug
https://issues.chromium.org/issues/339298411Measurement
We will implement UseCounters for this pseudo element (and all the other too, see https://issues.chromium.org/issues/381093928)Estimated milestones
| DevTrial on desktop | 135 |
| DevTrial on Android | 135 |