- From: vmpstr via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Jan 2021 16:53:43 +0000
- To: public-css-archive@w3.org
> They can, it's just very special cased behavior. For most display locked content it is as if we simply skipped the rendering, but it still returns the correct values if queried, so to extend that to the scrollable content it would make more sense if these values were considered part of the "hidden" subtree - i.e. updated if queried but otherwise not visible from the outside effectively moving the scrolling content inside the "contained" subtree. I think we have one of these options: 1. Empty scrollbar + returns updated scrollHeight 2. Empty scrollbar + returns 0 scrollHeight 3. Non-empty scrollbar + returns updated scrollHeight (Non-empty scrollbar + returns 0 scrollHeight doesn't really make sense) If we're in either 1 or 2, then I feel like returning updated height is not correct since visually it's an empty scrollbar. If we are to return an updated height, then I would imagine we want a non-empty scrollbar, no? In that case, we of course would be in trouble because we either always have to keep it updated or risk exposing when contents are updated. Honestly, I don't think this is a big issue in terms of actual use-cases. I agree we should do something that makes sense, so if an empty scrollbar with an updated scrollHeight is the best thing we can expose, then I don't mind. I buy your argument that it is more consistent with the fact that we return proper sizes for elements of this subtree. > We wouldn't run anchoring while the contents were hidden, but rather save the anchor node before hiding, and then restore it after the content is no longer hidden, effectively treating the entire duration while the scrollable content was hidden as if it was a single layout update. The candidate selection is also not trivial, but doable. I would say that we still want to 1. restore the scroll offset and then maybe 2. do the scroll anchoring adjustment, since it's possible that the anchor element is gone and it's also possible that we couldn't select a viable candidate. IOW if it's gone or wasn't available to begin with, I wouldn't want the scroll offset to be reset to 0. That seems like a weird experience that sometimes we restore the scroll offset and sometimes it's 0 depending on which element is removed and which candidate we picked for anchoring. That being said, I think just restoring the scroll offset gets us 90+% of a good experience and adding a scroll adjustment after that might not be worth it? -- GitHub Notification of comment by vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5869#issuecomment-760323546 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 January 2021 16:53:46 UTC