Intent to Experiment: Beforematch event and hidden-matchable

97 views
Skip to first unread message

Joey Arhar

unread,
Aug 12, 2020, 5:00:18 PM8/12/20
to blink-dev

Contact emails

jar...@chromium.org


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

https://www.chromestatus.com/feature/5400510406328320

Thomas Steiner

unread,
Aug 12, 2020, 7:42:33 PM8/12/20
to Joey Arhar, blink-dev
--
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.
--
Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac)

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

unread,
Aug 13, 2020, 5:49:16 PM8/13/20
to Thomas Steiner, Joey Arhar, blink-dev
Thanks for working on this! It seems like a worthy problem to solve (and one that I run into when using find-in-page as a user).


On Thu, Aug 13, 2020 at 1:42 AM 'Thomas Steiner' via blink-dev <blin...@chromium.org> wrote:


The explainer is great, thanks!
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?
 


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


Did we ask?
 

Web developers: No signals


Do we have developers and partners lined up to experiment?
 

Joey Arhar

unread,
Aug 14, 2020, 4:11:37 PM8/14/20
to Yoav Weiss, Thomas Steiner, blink-dev
Thanks for reviewing this Yoav!

> The explainer is great, thanks!
> 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?

I have not implemented any cross-frame functionality yet, so at least for the origin trial this will not be a security concern. I have not started any discussions about this yet.

> 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?

AMP plans to experiment with this API for finding content within collapsed sections. Wikipedia is also interested in this API and may experiment, we plan to discuss it with them.

Yoav Weiss

unread,
Aug 14, 2020, 5:33:56 PM8/14/20
to Joey Arhar, Thomas Steiner, blink-dev
LGTM to experiment!
Reply all
Reply to author
Forward
0 new messages