https://github.com/WICG/display-locking/blob/master/explainer-beforematch.md
https://github.com/WICG/display-locking/blob/master/explainer-beforematch.md
https://github.com/w3ctag/design-reviews/issues/511
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.
https://groups.google.com/a/chromium.org/g/blink-dev/c/QKUZ_ALJdM8/m/d0Qu1wJcAQAJ
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
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.
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.
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
Gather developer feedback and get metrics on how often users search for text in hidden-matchable sections which get expanded by beforematch.
This origin trial will start at M86 and end at M89, lasting for three releases from M86-M88 inclusive.
None
There are no DevTools features for the scrolling, URL fragment, and event firing impacts that beforematch has.
Yes
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/
--
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.
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.