- From: x-Jake-x via GitHub <sysbot+gh@w3.org>
- Date: Thu, 01 Oct 2020 23:32:54 +0000
- To: public-css-archive@w3.org
The draft currently says > ISSUE 3: should overflow: clip also clip the scrollable overflow or should it remain a pure paint-time operation, which would mean that scrollable overflow, while invisible, would still be scrollable. but it also says > `clip` This value indicates that the box’s content is clipped to its overflow clip edge and that no scrolling user interface should be provided by the UA to view the content outside the clipping region. In addition, unlike overflow: hidden which still allows programmatic scrolling, overflow: clip forbids scrolling entirely, through any mechanism, and therefore the box is not a scroll container. My first impression is that `scrollWidth` and `scrollHeight` should be able to be retrieved programmatically in order to determine to what extent something can or should be scrolled. Since `clip` by definition seems to indicate it cannot be scrolled, the "50" that @bfgeek mentions above seems to make sense. HOWEVER -- if we look at ISSUE 3 a bit more technically -- it seems like it would completely redefine the `clip` value entirely by saying "This IS a scrollable container, but scrolling to the end of the overflow area would not show more of the content that was previously clipped." I can't think of a practical use case for this, but that doesn't mean there isn't one. As an impractical use case (at least impractical to me at the moment), the draft also says: >The scrollable overflow area is the union of: >the box’s own content and padding areas When we say "the box's own content" -- are we referring to elements, text, etc. within the parent box -- and is background considered part of that "content"? If background is not defined as part of content, then allowing ISSUE 3 to define `clip` as a pure paint-time operation and be scrollable would have to programmatically allow the scroll of the area in such a way that additional parts of the background could be revealed while simultaneously shrinking and shifting the box content -- think a "parallax" effect around the content -- at which point the "100" seems to make more sense to me. -- GitHub Notification of comment by x-Jake-x Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5572#issuecomment-702449661 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 1 October 2020 23:32:56 UTC