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

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

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`


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

So I see that the cons section lists "There is no way in CSS to say "change my style if a descendant has a pseudo class on it.". I am not a CSS expert but maybe this should be added? @plinss @atanassov 

> 3\. See if the match is where one would expect it to be (e.g. in the same DOM position)

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





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