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