Intent to Prototype: Beforematch event

[Joey Arhar]

Contact emails jar...@chromium.org Explainer https://github.com/WICG/display-locking/blob/master/explainer-beforematch.md Design docs/spec No design doc 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 element fragment navigation, whichever element has the target id. Motivation With the evolution of the web, there are always new and interesting ways that developers choose to organize the information on their pages. Some of these approaches (e.g. the common case of text scrolling), lend themselves naturally to user-agent features like find-in-page. This is not an accident, since find-in-page was designed with common use-cases in mind. However, other approaches like collapsed sections of text do not work well with user-agent features since the page does not get any indication that the user initiated a find-in-page request, fragment navigation, or scroll-to-text navigation. The beforematch event is a step in the direction that allows developers to leverage information that the user-agent already has to make these search and navigation experiences great. Specifically, with hidden but matchable content, it will be possible to process text for find-in-page match in sections that are not visible. In turn, the beforematch event will be fired on hidden (a.k.a. collapsed) sections, allowing the developer to unhide the section. The net effect is that the user is able to use find-in-page or link navigation to find content in collapsed sections -- something that is not currently possible. Even without hidden but matchable features, beforematch is a useful signal to the page which allows custom styling of the matched element, which is now only possible with approximations from scroll positions and intersection observations. Risks

Interoperability and Compatibility 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. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals Ergonomics 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. 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.

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

This intent message was generated by Chrome Platform Status.

[Stephen Mcgruer]

Hey Joey,

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

I don't see any match (hah) for 'beforematch' in that directory - https://source.chromium.org/search?q=beforematch&sq=&ss=chromium%2Fchromium%2Fsrc:third_party%2Fblink%2Fweb_tests%2Fwpt_internal%2Fdisplay-lock%2F&originalUrl=https:%2F%2Fcs.chromium.org%2F .

Can you point me more specifically at the tests you intend to upstream? Thanks!

--
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/CAK6btwKpSu2%2Bzw1gYOdGgFDbBQsBOYR54WupQn0Rnfmg0j%3D9ig%40mail.gmail.com.

[Joey Arhar]

Hey Stephen,

I see how that was misleading, my bad. After I land the patch to implement beforematch, there will be a directory in there called "beforematch": https://chromium-review.googlesource.com/c/chromium/src/+/2068873

I decided to wait until monday to merge the patch.

[Stephen Mcgruer]

> I see how that was misleading, my bad. After I land the patch to implement beforematch, there will be a directory in there called "beforematch": https://chromium-review.googlesource.com/c/chromium/src/+/2068873

I decided to wait until monday to merge the patch.

Ah, I had totally missed that this was an I2P, not an I2S. My bad, sorry - and glad to see a test suite nice and early :)

Is there any additional test support you would need in WPT to complete your testing story, or does it cover your needs today?

[Joey Arhar]

> Is there any additional test support you would need in WPT to complete your testing story, or does it cover your needs today?

As mentioned in the TODOs in some of the tests, I’m going to add more test cases once we nail down the desired behavior here: 

https://github.com/WICG/display-locking/issues/150

[Emilio Cobos Álvarez]

The explainer references content-visibility: hidden-matchable, but that
value isn't in the draft spec [1].

What is the relationship between content-visibility and beforematch?

Thanks,

-- Emilio

[1]:
https://wicg.github.io/display-locking/index.html#propdef-content-visibility

On 5/2/20 12:36 AM, Joey Arhar wrote:
> Contact emails...@chromium.org
> <mailto:jar...@chromium.org>Explainerhttps://github.com/WICG/display-locking/blob/master/explainer-beforematch.md
> <https://github.com/WICG/display-locking/blob/master/explainer-beforematch.md>Design
> docs/specNo design doc
> <https://www.chromestatus.com/admin/features/launch/No%20design%20doc>TAG reviewhttps://github.com/w3ctag/design-reviews/issues/511
> <https://github.com/w3ctag/design-reviews/issues/511>SummaryThe

> 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 <http://example.com/#foo>) -

> scroll-to-text navigation (example.com/#:~:text=foo

> <http://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 element fragment navigation,

> whichever element has the target id. MotivationWith the evolution of the

> beforematch. /Firefox/: No public signals /Edge/: No public signals
> /Safari/: No public signals /Web developers/: No signals Ergonomics This

> API is likely to be used in tandem with display locking AKA
> content-visibility: https://github.com/WICG/display-locking
> <https://github.com/WICG/display-locking> 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.

> DebuggabilityThere 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
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?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/
> <https://cs.chromium.org/chromium/src/third_party/blink/web_tests/wpt_internal/display-lock/>Link
> to entry on the Chrome Platform
> Statushttps://www.chromestatus.com/feature/5400510406328320
> <https://www.chromestatus.com/feature/5400510406328320>
> This intent message was generated by Chrome Platform Status

> <https://www.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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKpSu2%2Bzw1gYOdGgFDbBQsBOYR54WupQn0Rnfmg0j%3D9ig%40mail.gmail.com

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKpSu2%2Bzw1gYOdGgFDbBQsBOYR54WupQn0Rnfmg0j%3D9ig%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Chris Harrelson]

Hi Emilio,

On Mon, May 4, 2020 at 12:25 PM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

The explainer references content-visibility: hidden-matchable, but that
value isn't in the draft spec [1]. 

 

What is the relationship between content-visibility and beforematch?

Correct, it's not. However, it is mentioned in the explainer here. In an earlier iteration of the Display Locking concept, something like the beforematch event was present. We subsequently concluded that

* beforematch has independent value from Display Locking (see example 2 from the beforematch explainer; another example is a height 0 clip that hides content)

* Display Locking should integrate with beforematch in the future; hence content-visibility: hidden-matchable

Since the use case of content-visibility: hidden-matchable is purely about its exposure to beforematch, we left it out of the spec until such time as beforematch has advanced to a shipping feature.

Chris

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/052f501b-dcd0-5a4c-16d2-8796088f54bb%40mozilla.com.

[PhistucK]

I have some concerns about being able to know that a find-in-page query is happening. Some websites try to charge users for finding information in a page and this could eliminate the option for the user. I have no concrete examples, but I somehow remember something like this existed.

If there is a browser feature that lets the user override any page-facing pieces of this functionality, I would not mind, otherwise, this may cripple some existing usage.

(I know render-only-when-is-in-the-viewport already breaks find in page and this proposal might help make those findable - that is great, as long as the basic functionality is not harmed)

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_pJ3uPyTct3iVK20vkeRFZYXFbjUsrdob9RQ4Dr4%2B7sA%40mail.gmail.com.

[Joey Arhar]

> I have some concerns about being able to know that a find-in-page query is happening. Some websites try to charge users for finding information in a page and this could eliminate the option for the user. I have no concrete examples, but I somehow remember something like this existed.

> If there is a browser feature that lets the user override any page-facing pieces of this functionality, I would not mind, otherwise, this may cripple some existing usage.

I agree. I feel like the best place to put this in the browser layer would be in privacy or something, which would let you basically disable beforematch on certain sites. However, I feel like the use case is too narrow to be allowed an entire privacy setting for it. Maybe we could somehow fold it into another privacy setting or create a new one that could encompass more stuff like disabling scroll-to-text... but I think it would be really difficult for users to recognize a site abusing beforematch, know a privacy setting exists to combat it, and then go change it.

Maybe it would make more sense to do the inverse, where sites aren't allowed to use beforematch by default and pop up a privacy thing where you have to click to allow the site to use beforematch, but I also think that would be so invasive and annoying to the user that it could defeat the purpose of beforematch.

I can't think of a great way to address this.

> (I know render-only-when-is-in-the-viewport already breaks find in page and this proposal might help make those findable - that is great, as long as the basic functionality is not harmed)

I've never heard of render-only-when-is-in-the-viewport, could you elaborate?

[Chris Harrelson]

On Tue, May 5, 2020 at 11:24 AM Joey Arhar <jar...@chromium.org> wrote:

> I have some concerns about being able to know that a find-in-page query is happening. Some websites try to charge users for finding information in a page and this could eliminate the option for the user. I have no concrete examples, but I somehow remember something like this existed.

> If there is a browser feature that lets the user override any page-facing pieces of this functionality, I would not mind, otherwise, this may cripple some existing usage.

I agree. I feel like the best place to put this in the browser layer would be in privacy or something, which would let you basically disable beforematch on certain sites. However, I feel like the use case is too narrow to be allowed an entire privacy setting for it. Maybe we could somehow fold it into another privacy setting or create a new one that could encompass more stuff like disabling scroll-to-text... but I think it would be really difficult for users to recognize a site abusing beforematch, know a privacy setting exists to combat it, and then go change it.

Maybe it would make more sense to do the inverse, where sites aren't allowed to use beforematch by default and pop up a privacy thing where you have to click to allow the site to use beforematch, but I also think that would be so invasive and annoying to the user that it could defeat the purpose of beforematch.

I can't think of a great way to address this.

> (I know render-only-when-is-in-the-viewport already breaks find in page and this proposal might help make those findable - that is great, as long as the basic functionality is not harmed)

I've never heard of render-only-when-is-in-the-viewport, could you elaborate?

I think he means that existing sites often use virtualization techniques to avoid rendering work for offscreen content. These techniques usually set display:none on all offscreen DOM, which avoids rendering cost, but as a side-effect prevents any UA features like find-in-page. Improving accessibility of this use case without giving up on avoiding rendering work for offscreen context is indeed a goal of berforematch and content-visibility.

[PhistucK]

I mean "infinite scrolling" lists where the code shows/hides (or even adds/removes) elements that are/are not close to the current viewport while you scroll, in order to increase performance, reduce memory and similar.

☆PhistucK

[Joey Arhar]

Ah yes, I understand now.

I suppose that if pages already have the power to prevent find-in-page from being usable by doing viewporting/virtual scrolling, is giving them beforematch as another tool to do so such a bad thing?

[PhistucK]

That was actually not my point :) They usually do that to prevent performance issues, not to prevent find-in-page and I noted that beforematch with content-visibility helps in those cases.

You are correct that they can do that (they can render all text in a canvas and that would do the trick as well, though). But having a standardized and easy way to do that might translate into more find-in-page preventions (since it does not require any heuristics, no trade offs).

I know it is not a strong case and probably more of a browser-preference/feature suggestion more than anything, but I thought it was important to bring to the table.

☆PhistucK