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: I proposed this property which allows UA to search for text inside hidden content which find in page and scroll to text<br>
&lt;dael> jarhar: Looking for resolution on 3 points. 1 is the general idea good? 2) is using content-visibility a good idea 3) does it make sense for script to be responsible to reveal or the browsers?<br>
&lt;dael> jarhar: Starting with 1 does it sound like a good idea?<br>
&lt;dael> TabAtkins: Yes, I like the feature. We should persue something<br>
&lt;dael> astearns: Anyone with opposite opinion?<br>
&lt;dael> smfr: Do we think authors can make rational decisions about to use hidden-matchable vs hidden? Is there a case where they would not want find in page behavior?<br>
&lt;dael> chrishtr: Yes, one example is when you want ot hide content which does not make sense for user. tabbed content and it's a previous view. Not in your current route so doesn't make sense to search<br>
&lt;dael> smfr: Makes sense<br>
&lt;dael> smfr: I think it's reasonable feature. Seems special-case-y<br>
&lt;dael> Rossen_: What was the use case?<br>
&lt;fantasai> s/special-case-y/special-case-y, I don't really like it/<br>
&lt;dael> jarhar: Use case if the user searches for something with find in page. Page has hidden content like mobile wikipedia where there's collapsed sections. User wants to find text inside the collapsed. Page should be able to show the sections in response to the search<br>
&lt;heycam> q+<br>
&lt;dael> TabAtkins: One use case for content-visibility is let page spam a bunch of content into the dom and this allows the dom content to be searchable even if not displayed<br>
&lt;smfr> q+<br>
&lt;dael> astearns: Rossen_ is that enough of an answer?<br>
&lt;dael> Rossen_: Thank you<br>
&lt;astearns> ack heycam<br>
&lt;dael> heycam: I don't have a strong opinion. Seems reasonable. I think we need to have some way to expose hidden content for searching. I wonder if some better names could be used. Seems clearly 2 use cases. content hidden away and not part of current presentation but some content hidden for virtual scrolling. Wonder if better names might help authors to use the right one. No specific suggestions<br>
&lt;astearns> ack smfr<br>
&lt;dael> smfr: On previous call I mentioned things in browsers that index content of web pages. Scroll to and find text isn't the only things that care. Browsers will index for selecting later. Somewhat concerned about a11y. Content must not be accessible to things such as tab order. WEird if you can find the content since there's a result in there if you're using voice over do you instantiate the content when voiceover goes there or are they hidden?<br>
&lt;dael> jarhar: I see the tab order point.<br>
&lt;dael> jarhar: I'm not very familiar with voice over or indexing pages for later use within browser features<br>
&lt;dael> TabAtkins: Tab order is intentional. Tabbing the auto-expended sections open. Good a11y the thing that expands the section should be tabbable. Don't know you should be able to tab in<br>
&lt;dael> vmpstr: No use cae where only way to find is via find in page. You can expand with tab or clcik. This is expanding to find via find in page. No case where only way to find it is find in page<br>
&lt;astearns> ack fantasai<br>
&lt;dael> chrishtr: For a11y doesn't make sense to expose to default order just like doesn't amke sense for tabbing because you're tabbing through what's seen right now. Would be good to expose find in page to cause hidden content to be shown when you search it<br>
&lt;dael> fantasai: Based on the use cases I think behavior of keeping out of tab order makes sense. I think targetting element using fragment ID should be similar to find in page. Possibly some other API<br>
&lt;dael> chrishtr: YOu lean fragment navigation?<br>
&lt;dael> fantasai: Yeah<br>
&lt;dael> jarhar: We were thinking of that earlier but got complicated when we impl async flow where make browser wait to scroll for two request animation frames so we give the page time to reveal the element before browser scrolls. Couldn't do the same thing for element fragment ID scrolling b/c page can observer sync change so we would need to not include the async step or break the current behavior<br>
&lt;dael> jarhar: Considering the page can see changes to fragment idea seemed like we could not fire before match on fragment IDs<br>
&lt;dael> fantasai: But then page needs to know if it's a dependant. If you looka t use cae with collapsable sections you want them to auto-expend even if someone gave you a link into the subsection. That shouldn't be worse than a text fragment ID. THe fact that the sub-section has an ID is a good thing and we shouldn't treat it as less convenient. Shouldn't make the author do extra work to support that<br>
&lt;dael> jarhar: Makes sense.<br>
&lt;dael> jarhar: Wondering about separating navigating to and script showing it. Not sure right now on the best path forward<br>
&lt;dael> astearns: WE're at time. Answer I'm hearing to the first question is yes it's a good idea but not just for the things you have defined. Good to flush out other ways of nav to other hidden places<br>
&lt;dael> smfr: Would like an explicit request for a11y input<br>
&lt;dael> astearns: I'll cut it off there<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-722059356 using your GitHub account


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

Received on Thursday, 5 November 2020 01:02:12 UTC