W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2021

Re: [csswg-drafts] [css-overflow] Is it necessary to support nested scrollers for html and body? (#5403)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 29 Jul 2021 22:05:43 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-889490847-1627596342-sysbot+gh@w3.org>
The CSS Working Group just discussed `Nested scrollers for HTML and BODY`, and agreed to the following:

* `RESOLVED: close no change, until time machine`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Nested scrollers for HTML and BODY<br>
&lt;Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5403<br>
&lt;fantasai> florian: If html has a value other than visible, we propagate that<br>
&lt;fantasai> florian: if it's visible, we propagate from body<br>
&lt;fantasai> florian: If both are scrollable, we get two scrollbars<br>
&lt;fantasai> florian: person filing issue suggests that's not very helpful<br>
&lt;fantasai> florian: maybe it's better to just accept one of these two values, whichever is not visible<br>
&lt;smfr> +1 to worry about the compat risk<br>
&lt;fantasai> florian: but the current behavior has been interop for a long time<br>
&lt;fantasai> florian: so there's a compat risk to changing<br>
&lt;fantasai> florian: question is to ask WG whether it wants to try to make such a change<br>
&lt;fantasai> TabAtkins: Do we have usage numbers on overflow on both html and body?<br>
&lt;fantasai> florian: optimistically, might be possible<br>
&lt;fantasai> florian: but would have to fetch data to prove it<br>
&lt;fantasai> TabAtkins: I can't see any way for the page to be depending on this<br>
&lt;emilio> q+<br>
&lt;fantasai> TabAtkins: what content would you put outside the body?<br>
&lt;fantasai> florian: Maybe ::before/::after<br>
&lt;fantasai> florian: or maybe multiple bodies<br>
&lt;fantasai> TabAtkins: can't do that due to HTML parser, unless you're injecting via script<br>
&lt;heycam> also doesn't seem like a big enough simplification to warrant the risk<br>
&lt;Rossen_> ack emilio<br>
&lt;astearns> +1 heycam<br>
&lt;fantasai> emilio: Agree with heycam that this doesn't seem hard, but it's not much of a simplification<br>
&lt;fantasai> emilio: if it helps authors, maybe then worth doing<br>
&lt;fantasai> emilio: case of overflow:auto on the root and overflow:hidden on the body to clip that... maybe not very useful<br>
&lt;fantasai> Rossen_: I'm hearing most people align with worry of compat risks<br>
&lt;fantasai> Rossen_: compared to minimum benefit that we get<br>
&lt;fantasai> Rossen_: we can close this as by design for now, and if anyone wants to fetch data to show that this design is bad and it is easy and low-risk to change<br>
&lt;fantasai> Rossen_: without that data, seems high risk for low benefit<br>
&lt;dbaron[m]> I think Tab was talking about Chromium's kBodyScrollsInAdditionToViewport use counter.<br>
&lt;TabAtkins> fantasai: this seems like a good idea, but since we have interop on current behavior and it's not too bad, don't htink it's worth implementing the change even if it doesnt' cause webcompat issues<br>
&lt;fantasai> florian: plus get several years of non-interop ...<br>
&lt;fantasai> Rossen_: So proposal is to close, acknowledging that the situation is imperfect<br>
&lt;fantasai> RESOLVED: close no change, until time machine<br>
&lt;dbaron[m]> yeah, the code for that use counter looks wrong<br>

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 July 2021 22:05:45 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:39 UTC