Re: [w3ctag/design-reviews] Beforematch event (#511)

Thanks for the feedback! Sorry for the slow reply, I took some time to compare with alternatives more closely and refine the explainer.

> This seems intrinsically linked to the content-visibility: hidden-matchable state described in the Display Locking explainer, so it would be helpful to have a bit more discussion on how that state came to be - specifically, why content-visibility: auto isn't sufficient for the "Deep links and searchability into pages with hidden content" case, which this proposal seems primarily concerned with.

`beforematch` is not intrinsically tied to `hidden-matchable`. For example, `beforematch` could be used to [expand text hidden inside of `<details>` elements](https://github.com/WICG/display-locking/issues/162) by firing the event on text hidden inside them without the use of `hidden-matchable`. On the other hand, `hidden-matchable` does indeed depend on `beforematch`.

The case that is handled by `content-visibility: hidden-matchable` is different from `content-visibility: auto`. Specifically, the `auto` case automatically makes the content visible to the user when it is inside the visual viewport (or nearby), without any help from the developer. This would be akin to regular content that appears when scrolled into view. The hidden-matchable case is more similar to the `<details>` element or mobile Wikipedia sections, where the content is not visible to the user even in the viewport (other than the `<summary>` content), and requires a different type of user intent to see the content (i.e. click to expand a hidden section).

> I struggled to fully understand the use case, even having read through the earlier discussion on #306, this explainer, and the Display Locking explainer mentioned above. Would it be possible to have a clearer description of exactly what problem this is solving?

This event helps with situations such as “collapsed sections of text” or other forms of content that is hidden unless shown by a user interaction (other than scroll). This is similar to the built-in `<details>` tag, which does not show the contents within it unless the user clicks specifically to open it.

This event allows the developer to provide the ability to search through such content, notifying the page when a match is found, which in turn allows the page to do what is necessary to show the text and reveal the full contents.

> One other note: "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" - this sounds like a use case that would be better served by a CSS pseudo-selector.

Regarding a pseudo-selector: that’s a good point. Styling a specific element could be achieved with a pseudo-selector. However, we don’t think this approach will work in more complex cases where ancestor or sibling elements need to be re-styled, or interaction with frameworks or virtual scrollers. I added an alternatives section to the explainer to elaborate on this [here](https://github.com/WICG/display-locking/blob/master/explainers/beforematch.md#alternatives)

> Also from the same virtual face-to-face review. My main concern with the proposal is somewhat captured with issue 150. The beforematch event opens the door for re-entrant code introducing easy to achieve circularity. The beforematch event fires >> the event handler removes the target DOM element >> another event handler handles the remove and adds it back to DOM >> etc.

> I appreciate that you're upfront listing the issues in your explainer however I didn't see good mitigation besides some ideas around scrolling specific logic. Can you provide more details as to how do you intend to stabilize this?

I do agree that there are some details to work out to mitigate this problem. In our experimentation, the only case we found in a “natural” page is that a section that expands may change layout, so the browser needs to be careful about [scroll positioning](https://github.com/w3c/csswg-drafts/issues/5018). In malicious sites (or sites with unfortunate bugs), the cyclic behavior is definitely possible. I would argue that this type of behavior is already possible in most event handlers that observe DOM changes though (examples: MutationObserver, IntersectionObserver, ResizeObserver, scroll event listeners (especially with scroll anchoring)). 

One proposal for mitigating this is to allow the user-agent to “give up” after some number of tries. So in the example of find-in-page, this would mean something like
1. Find a match
2. Call the beforematch handler
3. See if the match is where one would expect it to be (e.g. in the same DOM position)
4. If yes, scroll to it
5. If no, and there were less than X tries for this particular request, then go back to step 1.

This will be possible because the source of the find-in-page is always a user agent action, not a script-driven action. For that reason also, the spec could suggest the user agent apply such a mitigation but not spell out the mitigation in detail.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/511#issuecomment-644348937