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

Thanks for taking another look at this!

> I think some more fleshed out use cases, separated out from the example code, would help guide the review here.

> So this is hidden-matchable and `<details>`, but are there really any other examples? I assume that newer custom elements implementing something like `<details>` will use content-visibility: hidden-matchable

I have no other examples. The intent of the feature is to allow searching into hidden content, and to allow revealing the content when a match is found. Hidden-matchable and the beforematch event make this possible when used together, and without both of them, we won’t have the desired feature. The details element could also benefit from beforematch since it has revealable hidden content, but it wouldn’t make a ton of sense to have it be the only way to use beforematch.

After thinking about it some more, I agree with these considerations: I think that we should combine the proposals for content-visibility:hidden-matchable and the beforematch event. Should I edit the title and description of this issue? [Here is the explainer for hidden-matchable](https://github.com/WICG/display-locking/blob/master/explainers/content-visibility-hidden-matchable.md).

> As an author, when would I use visibility: hidden as opposed to content-visibility: hidden-matchable if I wanted the content to be available to find-in-page in this way?

The explainer may have been a bit misleading - visibility: hidden text is not and will not be available to find-in-page. [I’ll update the explainer to make it less misleading](https://github.com/WICG/display-locking/pull/183).

> Given visibility: hidden content is hidden from assistive technology, how would this change in behaviour impact assistive technology users?

content-visibility: hidden-matchable hides content the same way visibility: hidden does. The native find-in-page feature can fire the beforematch event on hidden-matchable content if a match is found, but we don't think it's possible for other find-in-page mechanisms built on top of the AX tree to fire this event. I don’t have a lot of expertise in assistive technologies, but I think that they don't have full access to the DOM and styles, so they would not be able to fire the beforematch event and scroll like find-in-page does.

> Similarly, several of the alternatives mention "Doesn't allow "unlocked" hidden-matchable content to become hidden again, which could get confusing." What does this mean? There is no use case which mentions this behaviour, so I'm not clear on how the proposed solution provides this benefit.

In a previous iteration of this feature, we had content-visibility: hidden-matchable without the beforematch event. When the user searched for text inside of these sections, the section would get revealed without the page being explicitly notified, and the style would remain hidden-matchable. In this case, there is no way for the page to make the selection collapsed again, which is desired in use cases which look similar to a details element where the user clicks on the title or arrow of the collapsible section to toggle the collapsing.
[I’ll revise the explainer to make this clearer](https://github.com/WICG/display-locking/pull/181).

To talk about a specific example, imagine a mobile wikipedia page with collapsed sections. Suppose you find some word, foo, in a collapsed section. This section would have to be revealed in some way. If the user then dismisses the find-in-page dialog, or continues onto the next match, then this section should remain open. However, either the browser makes this state of being expanded sticky (meaning that the script can’t collapse the section anymore), or the section collapses automatically when there is no longer a match (which is not desired behavior). This case can be addressed by firing a beforematch event and letting script design on the correct course of action.

> Couldn't you use querySelector() to find the match target, then use the same script you would use on the beforeMatch event target? What am I missing here?

It seems like there isn’t a way to listen for changes in pseudoclasses. This means that it’s unclear when to run this querySelector / script. Even if there was a way you could with a MutationObserver, I think that a DOM event like beforematch is more ergonomic. It would also be challenging to make sure the timing works out well - right now, we make sure that the beforematch event is fired before find-in-page tries to scroll so that script can reveal the content before it gets scrolled to. However, if the page were to try to do this with a MutationObserver, trying to time the find-in-page scroll would be more challenging.

> How exactly do you do this? If it was collapsed before, how do you know the intended position before laying it out?

We are only looking at the DOM position, which is independent of the layout/position on screen. If the matching text is removed from the DOM, then we will continue the search and fire the beforematch event again.



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