- From: L. David Baron via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 May 2018 23:45:09 +0000
- To: public-css-archive@w3.org
Also, I guess I've looked through the uses of the term now (which I probably should have done earlier), and I suppose I see that given the uses are all related to the APIs that cause movement on scrolling, why you'd want to condition it on having scrollable overflow. However, it seems like that usage precludes things like being able to control whether removal of content (*if* it causes a box to no longer have overflow) triggers a smooth or instant scroll. So even given that usage, it seems better to have the term be consistently defined whether or not there's currently overflow, and handle all cases of the scrollable range changing consistently, whether or not the change in the scrollable range means there's no longer any room for movement. And it seems like the restrictions on the range you're able to scroll to should be able to handle all the cases that not being able to scroll at all can. (I'd also note that sometimes there's scrollable overflow that doesn't cause any ability to scroll, e.g., if it's above the scrollport.) -- GitHub Notification of comment by dbaron Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/1540#issuecomment-386761438 using your GitHub account
Received on Friday, 4 May 2018 23:45:13 UTC