Re: [csswg-drafts] [css-contain-2] Proposal: content-visibility: hidden-matchable (#5595)

The CSS Working Group just discussed `[css-contain-2] Proposal: content-visibility: hidden-matchable`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic:  [css-contain-2] Proposal: content-visibility: hidden-matchable<br>
&lt;dael> github:  https://github.com/w3c/csswg-drafts/issues/5595<br>
&lt;dael> jarhar: Couple of things I'd like to resolve quickly<br>
&lt;dael> jarhar: Like to resolve 1) do we have agreement it's useful to have a way to spec hidden content that's searchable in general<br>
&lt;dael> jarhar: 2) Seems like in previous discussions we've talked what algos and things the searching should be exposed to. I'd like to get resolution that this feature should work for all methods of seatching UA provides and all web APIs for searching<br>
&lt;dael> jarhar: If we get those then we can discuss if content-visibility:hidden-matchable is right<br>
&lt;dael> jarhar: Issues with in general having this feature?<br>
&lt;smfr> q+<br>
&lt;dael> Rossen_: Question here, we're talking about searching and a lot of that doesn't lend naturally to css. Meta question for searching is if content presented visually is also available in the DOM so it can be indexed and searched<br>
&lt;dael> Rossen_: And how does that relate to assistive technologies and other layers using that approach. Those are the layers to hit before answering if searchable. Is that fiar?<br>
&lt;dael> jarhar: Was question about a11y? There has been discussion on GH about a11y. Earlier Chris mentioned previous discussion about how a11y tree shows content-visibility auto or hidden content<br>
&lt;dael> Rossen_: My question was if this hidden-matchable is presented to a11y it sounds like your answer is most likely yes it's visible so question is about if it's visible to search<br>
&lt;dael> chrishtr: Question is if it's good to have a way to have content in dom which is hidden from visual display but exposed to ways to search in the document, find in page, reader modes, a11y tools. Correct?<br>
&lt;dael> Rossen_: Yes. And how and where does css play a role since it's mostly visual layer<br>
&lt;dael> Rossen_: If what you're saying...if all the methods you desc will be able to get to the content besides what we paint on screen I think the answer lends easily for if it's available to search<br>
&lt;dael> Rossen_: I think I got my answer. Want to go to queue<br>
&lt;dael> smfr: Two points. One is content-visibility as I understand is optimization so UA doesn't hav e to build render tree. Issue with allowing finding inside is if UA on every page load tries to look for readerizable content it means every page load your hidden-matchable content will still need to be figured out enough to give right answer to indexing code. So you lose the optimization<br>
&lt;fantasai> [smfr mentions that 'visibility' and 'display: none' need to be resolved, for example]<br>
&lt;dael> smfr: Second, anybody who wrote browser code knows you have to think about is content hidden by style, hide from APIs not just visually. display:none does, visibility-hidden sometimes does. Now we have 2 more and I'm uncomfortable adding more variations to is this content available in this scenario<br>
&lt;fantasai> s/visibility-hidden/visibility:hidden/<br>
&lt;dael> chrishtr: Yes, if UA on initial load always indexes and goes into hidden-matchable subtrees performance advantage is lost. I would recommend doing it in a smarter way that doesn't interfere with performance<br>
&lt;dael> chrishtr: This is an additional feature which is different and therefore has a cost of impl complexity. It is useful, though, b/c it's common to have collapsed sections or offscreen that's not rendered for performance but should still be searchable. For that reason I think it's justified<br>
&lt;dael> smfr: I think you said for first point that yes UA has to do the work and in some UAs the advantange can be lost but depends on what UA does.<br>
&lt;dael> chrishtr: I would say it depends on what UA is allowed to do and UA should be allowed to index. There are definitely performance footguns to avoid<br>
&lt;florian> [In the abstract, I feel confortable with the intent of proposed resolution 1 and 2 as initially exposed, but the concerns raised by smfr seem very relevant to me]<br>
&lt;dael> Rossen_: smfr does that satisfy your questions?<br>
&lt;dael> smfr: I guess. It seems unfortunate that the UA can trigger potentially expensive content building in this case<br>
&lt;dael> florian: Clarification question. smfr if I'm hearing you in your view searching and indexing are not separate. index powers the search. Or is index for something other than search?<br>
&lt;dael> smfr: Original obj was why is cmd+f special. There's more indirect. Safari indexes and in other parts of OS you search and get the webpage. And ideally the results would be the same as you cmd+F on the web page. That's why we're saying it should be same results.<br>
&lt;dael> TabAtkins: Seems like that's what htis is intending to do better. Something hideen-matchable is intended to be exposed. ctl+f is off of dom<br>
&lt;dael> smfr: It doesn't. ctr+f doesn't find display:none things. So we run off of display:none type things resolved. If you have display:none inside c-v:h-m content you don't want that to show<br>
&lt;dael> TabAtkins: So you're talking about expensive rendering is pulling something from dom so it shows up in structure for indexing<br>
&lt;dael> smfr: Right and thats up until you render which is fairly expensive<br>
&lt;dael> chrishtr: There is a significant cost, yes. UA should be allowed to index but do so in a way that doesn't harm perf. This is an additive thing b/c shouldn't index thigns that are display:none. It's an advantage to a11y but UA needs to be careful on how you schedule work<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> ack smfr<br>
&lt;smfr> q-<br>
&lt;dael> florian: Could do most of the page and have hidden-matchable as lazy parts. People don't search in ms of load<br>
&lt;dael> chrishtr: Right, something like lazy background processing<br>
&lt;dael> Rossen_: We're in the time allocated. I don't hear alignment to resolve on the two initial asks. I also see lots of conversation in GH. Happy to give it another 10 minutes next week if the general consensus is achieved on issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-737576052 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 3 December 2020 00:20:58 UTC