The beforematch event allows developers to display content to the user in response to the following actions: - find-in-page (ctrl+f) - 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.
Interoperability risks: There are no signals on this feature from firefox or safari 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.
This API is likely to be used in tandem with display locking AKA content-visibility: https://github.com/WICG/display-locking I don't foresee any performance issues with using beforematch at the moment.
This feature will benefit from having example code in the explainer repo to show developers how to use it.
I don't have any security considerations for this feature.
Gather developer feedback and get metrics on how often users search for text in hidden-matchable sections which get expanded by beforematch.
This original origin trial was M86-M88 inclusive. This extension would include the experiment in M89 and M90, then turn off the origin trial in M91.
None
There are no DevTools features for the scrolling, URL fragment, and event firing impacts that beforematch has.