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 <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/CAARdPYf2sdcZCqkro5JKmfagxDw6Wo4F%3Dx7CM6Z2-qwky8r0ug%40mail.gmail.com.
