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

Thanks for bringing this review to us. We are looking at this at our virtual face-to-face.

This seems intrinsically linked to the `content-visibility: hidden-matchable` state described in the [Display Locking explainer](https://github.com/WICG/display-locking), 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.

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?

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.

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