- From: Simon Fraser via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Dec 2020 04:41:34 +0000
- To: public-css-archive@w3.org
> * What are the "addresses" and "metadata" use cases you talked about? I brought these up because I think adding CSS behaviors for a single browser feature like Find is odd. Find isn't necessarily the only way that UAs look for things in page content. addresses: WebKit API has a way for clients to ask for all the identified bits of metadata in certain categories in the content (e.g. addresses, telephone numbers), and these can be matched eagerly. metadata: Safari indexes locally the text content of pages that you visit for Spotlight (searching outside of the browser can offer up a link to a page that you have previously visited). 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. 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? -- GitHub Notification of comment by smfr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-736985703 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 04:41:35 UTC