Re: [csswg-drafts] [css-contain] Should scrollIntoView scroll to content-visibility: hidden subtree elements (#6529)

The CSS Working Group just discussed `scrollIntoView() with content-visiblity:hidden`, and agreed to the following:

* `RESOLVED: c-v:hidden prevents scrollIntView() and similar functionality from working on the subtree`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: scrollIntoView() with content-visiblity:hidden<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6529<br>
&lt;leaverou2> Fine by me to bump, that gives me more time to join the call for the nesting issue too<br>
&lt;TabAtkins> vmpstr: We have content-visiblity:hidden that hides the content of the subtree, and spec says that the contents should not be available to UA features like focus, find-in-page, etc<br>
&lt;TabAtkins> vmpstr: I think one of the features it should be restrited from is fragment nav<br>
&lt;TabAtkins> vmpstr: I don't want to scroll into the hidden content<br>
&lt;bradk> Is content-visibility in a draft?<br>
&lt;TabAtkins> vmpstr: But the current fragment nav text points to scrollIntoView() for defining it. and sIV() says we scroll as long as there's a layout box<br>
&lt;TabAtkins> vmpstr: My hope is we can prevent sIV() for c-v:hidden subtrees<br>
&lt;astearns> bradk: https://drafts.csswg.org/css-contain-2/#content-visibility<br>
&lt;TabAtkins> vmpstr: I think last comment from Chris is that we should change sIV() to say "if it doesn't ahve a layout box, or is not available to UA features, return"<br>
&lt;bradk> @astearns thanx<br>
&lt;TabAtkins> TabAtkins: I support this<br>
&lt;chris> rrsagent, here<br>
&lt;RRSAgent> See https://www.w3.org/2021/08/25-css-irc#T16-10-24<br>
&lt;leaverou2> Does that mean we also don’t scroll to disabled form controls since they can’t be focused?<br>
&lt;TabAtkins> vmpstr: To be specific we gen the layout box in the subtree when we *need* to, such as to getBoundingClientRect() on the subtree<br>
&lt;TabAtkins> vmpstr: So the layout box *is* theoretically there, but it's generated on demand. We just don't want that to happen here.<br>
&lt;TabAtkins> Rossen_: Can we get a tighter definition for "available to UA features"? It's very broad<br>
&lt;TabAtkins> Rossen_: What would be the better scoped version of that? Is it just for focusing?<br>
&lt;chrishtr> q+<br>
&lt;TabAtkins> vmpstr: I think it should be "behaving similar to display:none", it's not just focus<br>
&lt;TabAtkins> vmpstr: display:none *also* doesn't have a layout box, but this does<br>
&lt;TabAtkins> chrishtr: We can scope it by "if you ahve a content-visiblity:hidden ancestor"<br>
&lt;TabAtkins> Rossen_: Okay so if it's hidden or has an ancestor<br>
&lt;TabAtkins> chrishtr: Only ancestor. If the element itself has it, it's still there on the page like normal<br>
&lt;leaverou2> But ancestor can’t be overridden by another ancestor lower down<br>
&lt;leaverou2> s/can’t/can/<br>
&lt;leaverou2> Perhaps if the computed value of the parent is c-v:hidden?<br>
&lt;TabAtkins> TabAtkins: I think best is to define the term somewaht generally, and say that c-v:hidden is the only way to trigger the term currently<br>
&lt;Rossen_> q?<br>
&lt;TabAtkins> Rossen_: Sounds reasonable<br>
&lt;Rossen_> ack chrishtr<br>
&lt;leaverou2> Agreed as well<br>
&lt;TabAtkins> Rossen_: Any more comments?<br>
&lt;TabAtkins> RESOLVED: c-v:hidden prevents scrollIntView() and similar functionality from working on the subtree<br>
</details>


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


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

Received on Wednesday, 25 August 2021 16:15:43 UTC