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

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

Yeah, it seems like these two APIs really form one conceptual API together.

It would make sense to combine the explainers as well, since one doesn't really work without the other. That combined explainer could use the Wikipedia mobile page example as an end to end example illustrating how to use the two APIs in conjunction to create a good user experience.

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

This is a great example. Are there any other kinds of interactions you had in mind while designing these APIs?

To flesh this out a little more, you might add some example code like:

```js
<h2>Cultural references</h2>
<section class="locked">
Octopus ...
</section>
```

So what I'm interested in here is the full flow, from loading the page, to matching "Octopus", to the section being closed again. What is the goal state here?

I'm guessing it's something like:

1. User loads the page. All subsections including "Cultural references" are hidden, with only the headings visible (similar to a `<details>` element).
2. User searches for "Octopus"
3. The `<section>` contents is made visible to the user
4. ???
5. The `<section>` contents is hidden from the user again.

Is that the flow you're designing for?

If so: what happens at step 4? How does the `beforematch` event enable it?

Also: at step 3, is it implied that the author must write code to remove the `hidden-matchable` style, by handling the `beforematch` event?

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