Intent to Experiment: Beforematch event and hidden-matchable
Joey Arhar
Contact emails
Explainer
https://github.com/WICG/display-locking/blob/master/explainer-beforematch.md
Design docs
https://github.com/WICG/display-locking/blob/master/explainer-beforematch.md
TAG review
https://github.com/w3ctag/design-reviews/issues/511
Summary
The beforematch event allows developers to display content to the user in response to the following actions:
- find-in-page (ctrl+f)
- element fragment navigation (example.com/#foo)
- scroll-to-text navigation (example.com/#:~:text=foo)
The event is fired at render timing before these actions scroll the page. The event is fired on the element which contains the text, or in the case of fragment navigation, whichever element has the target id.
This origin trial will also enable the content-visibility: hidden-matchable CSS property. The hidden-matchable value is the same as content-visibility: hidden, but find-in-page and scroll-to-text can search the text inside of it and fire the beforematch event on the hidden elements, allowing the page to make find-in-page work on hidden content.
There was an Origin Trial of an earlier iteration of this API. Based in part on feedback from that trial, we substantially changed the API. The new API is different in terms of ergonomics and certain critical details about timing of events and scrolling in order to ensure good UX.
Link to “Intent to Prototype” blink-dev discussion
https://groups.google.com/a/chromium.org/g/blink-dev/c/QKUZ_ALJdM8/m/d0Qu1wJcAQAJ
Risks
Interoperability and Compatibility
Interoperability risks: There are no signals on this feature from Gecko or WebKit yet. We have some tests that use WPT test infrastructure that we can upstream to WPT when the time comes.
Compatibility risks: This feature will slightly change the way the scroll-to-text-fragment and find-in-page features work, but since scroll-to-text-fragment is not implemented in other browsers yet, and find-in-page is not specced, this will not cause Chrome to diverge in behavior from other browsers. For element fragment scrolling, there are WPTs which make sure the element fragment behavior is not changed by beforematch.
Gecko: No signal
WebKit: No signal
Web developers: No signals
Ergonomics
This API is likely to be used in tandem with content-visibility.
I don't foresee any performance issues with using beforematch at the moment.
Activation
This feature will benefit from having example code in the explainer repo to show developers how to use it.
Security
I don't have any security considerations for this feature.
I do have some privacy considerations which I described in this security and privacy self review: https://github.com/WICG/display-locking/blob/master/privacy-assessments/beforematch.md
There was also some brief discussion about this in the intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/QKUZ_ALJdM8/m/d0Qu1wJcAQAJ
Goals for experimentation
Gather developer feedback and get metrics on how often users search for text in hidden-matchable sections which get expanded by beforematch.
Experimental timeline
This origin trial will start at M86 and end at M89, lasting for three releases from M86-M88 inclusive.
Ongoing technical constraints
None
Debuggability
There are no DevTools features for the scrolling, URL fragment, and event firing impacts that beforematch has.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
No. There are some tests for this feature which use the WPT testing infra which we can upstream to WPT later: https://cs.chromium.org/chromium/src/third_party/blink/web_tests/wpt_internal/display-lock/
Link to entry on the Chrome Platform Status
Thomas Steiner
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJ4woWwZGYSxp2CPyxr9oJWi7uFVCWgX8aSm9hNjVt%2Bzw%40mail.gmail.com.
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1.23 (GNU/Linux)
iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/
-----END PGP SIGNATURE-----
Yoav Weiss
TAG review
https://github.com/w3ctag/design-reviews/issues/511
Summary
The beforematch event allows developers to display content to the user in response to the following actions:
- find-in-page (ctrl+f)
- element fragment navigation (example.com/#foo)
- scroll-to-text navigation (example.com/#:~:text=foo)
The event is fired at render timing before these actions scroll the page. The event is fired on the element which contains the text, or in the case of fragment navigation, whichever element has the target id.
This origin trial will also enable the content-visibility: hidden-matchable CSS property. The hidden-matchable value is the same as content-visibility: hidden, but find-in-page and scroll-to-text can search the text inside of it and fire the beforematch event on the hidden elements, allowing the page to make find-in-page work on hidden content.
There was an Origin Trial of an earlier iteration of this API. Based in part on feedback from that trial, we substantially changed the API. The new API is different in terms of ergonomics and certain critical details about timing of events and scrolling in order to ensure good UX.
Link to “Intent to Prototype” blink-dev discussion
https://groups.google.com/a/chromium.org/g/blink-dev/c/QKUZ_ALJdM8/m/d0Qu1wJcAQAJ
Risks
Interoperability and Compatibility
Interoperability risks: There are no signals on this feature from Gecko or WebKit yet. We have some tests that use WPT test infrastructure that we can upstream to WPT when the time comes.
Compatibility risks: This feature will slightly change the way the scroll-to-text-fragment and find-in-page features work, but since scroll-to-text-fragment is not implemented in other browsers yet, and find-in-page is not specced, this will not cause Chrome to diverge in behavior from other browsers. For element fragment scrolling, there are WPTs which make sure the element fragment behavior is not changed by beforematch.Gecko: No signal
WebKit: No signal
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLmwh87Pqwya38bmfmjxkCR2YqTnaxoq68%2BWE%3DHHonvFVQ%40mail.gmail.com.
Joey Arhar
> One point there is "Some consideration needs to be given to the beforematch event when it comes to cross frame interactions. Specifically, if the matched information is found within a frame, should the signal propagate to the embedding page?"
> Was this question settled? Was this discussed with security folks?
> Is there a spec?
There is now: https://github.com/WICG/display-locking/blob/master/explainers/beforematch-spec-draft.md
> Did we ask?
We have had multiple discussions with Gecko about this API and earlier iterations here: https://github.com/mozilla/standards-positions/issues/135
We have not reached out to WebKit directly yet, but plan to relatively soon, once there is a draft spec.
> Do we have developers and partners lined up to experiment?