- From: vmpstr via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Dec 2020 22:50:19 +0000
- To: public-css-archive@w3.org
> In both cases, page content is traversed via the renderer tree (i.e. taking styles like `display:none` and `visibility:hidden` into account). My issue with `content-visibility: hidden-matchable` is that it focusses too narrowly on the Find use case, and not on other use cases like these which also involve searching page content, but more indirectly. Thank you for the examples. I agree that the spec should allow the UA to traverse/search through the hidden-matchable content to support these use cases. > Secondarily, a question: UAs can't run their Find In Page logic in `content-visibility: hidden` content without actually doing style resolution, because they need to know if the find result will end up inside `display:none` or `visibility:hidden` content. I think that implies that UAs would have to do some amount of render tree building in order to implement Find inside `content-visibility: hidden-matchable`. Is that something you've considered? That’s a good point. In our prototype in Blink, we do recalc style, build the layout tree and do some layout as well in order to support this feature, which is necessary, as you said. > Also how is `content-visibility: hidden-matchable` expected to interact with UA features like Reader view? If the content is important enough to allow Finding, should it be included in Reader views? Reader view sounds similar to Spotlight indexing. So I think hidden-matchable content could also be exposed to Reader. -- GitHub Notification of comment by vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-737543404 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 December 2020 22:50:21 UTC