-
Notifications
You must be signed in to change notification settings - Fork 756
Description
I am reimplementing overflow in Chrome, and need clarification of size of scrollable overflow region.
The issue I am concerned was mentioned in css-overflow-3
There’s disagreement on the scrolling model. 2.1 apparently defined that you scrolled the content area; the content would overflow the content-box, and you would union that overflow with the content box to find the scrollable area. In particular, this means that the content would be offset by the start-sides padding, but if it overflowed, it would go right to the edge on the end sides. This is what Firefox and IE do.
At least some authors (and spec authors) instead have the mental model that the padding box is what’s scrollable, so when you scroll to the end of the overflow, there’s the right/bottom padding. Chrome/WebKit do this for the block axis, at least. They’re somewhat inconsistent for the inline axis; there’s something weird about how they handle lineboxes.
It seems that the block-axis padding is probably web-compatible to honor. It’s unclear that the inline-axis padding will be. Further experimentation is needed.
In css-overflow-4 this issue is not addressed directly. From reading the spec, my best guess is that content area is scrollable, and not the padding area.
Is my reading of the spec correct?
Example:
.container {
width: 100px;
height: 100px;
padding: 30px;
overflow: scroll;
}
.target {
width: 200px;
heigth: 200px;
}
<div class="container">
<div class="target"></div>
</div>
In this example, according to the spec:
.container.scrollHeight = .container.paddingTop + .target.height
.container.scrollWidth = .container.paddingLeft + target.width
.container.paddingRight & .container.paddingBottom are not used to compute scroll height.
Existing browsers: do they use padding to compute scrollable overflow?
Chrome: bottom yes, right no
Safari: bottom yes, right no
Firefox: bottom no, right no
Edge: bottom no, right no
IE: bottom yes, right yes