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

@josepharhar Sorry for the slow response!

> ... On the other hand, `hidden-matchable` does indeed depend on `beforematch`.

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

For example, the introduction mentions 'visibility: hidden' subtrees, but that is not covered in a use case. Given 'visibility: hidden' subtrees are usually expected to be hidden from the user in every way, this seems worth expanding on. 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? Given `visibility: hidden` content is hidden from assistive technology, how would this change in behaviour impact assistive technology users?

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.

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

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?




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