[css-overflow-3] Scrollable Overflow contributions of zero height/width elements #4791
Comments
|
We seem to have interop across Gecko/Blink/WebKit that the tall block-level element contributes to overflow, and none of the others do. |
|
Specifically for the inflow case this is affecting the "inflow" bounds, the element isn't directly contributing overflow itself. You can test this by adding a transform to both elements - neither affect the scrollable area. |
|
The CSS Working Group just discussed The full IRC log of that discussion<fantasai> Topic: Scrollable overflow<fantasai> github: https://github.com//issues/4791 <fantasai> fantasai: Seem to have weird but interoperable behavior here, question was should we spec it <fantasai> iank_: not so weird, we compute the "inflow" bounds <fantasai> iank_: ... <fantasai> iank_: If you add a transform to the item and move it outside the scrollable area <fantasai> iank_: all browsers transform out <fantasai> iank_: if something is zero area, it doesn't itself contribute, but it might contribute to "infow bounds" <fantasai> fantasai: ??? <fantasai> iank_: If you have something like a grid area, that's where we determine where to put the "padding" to contribute to overflow <fantasai> iank_: Here it's the body element contributing to the scrollable area <fantasai> fantasai: OK, so need to set body to zero to test correctly and issue is invalid? <fantasai> iank_: question of adding to overflow is just if it's empty <fantasai> fantasai: Actually, there is an issue, but it's just that if the border area is empty, we need to exclude from the scrollable area <fantasai> iank_: yea, but also this other thing |
|
OK, 1. so the testcases need to add html, body { height: 0; } to work properly and 2. we need to spec that boxes with empty area do not contribute to scrollable overflow. If I understood @bfgeek correctly? |
|
Thats correct. At least "directly" to scrollable overflow. They can indirectly contribute to scrollable overflow via something like: <!DOCTYPE html>
<div style="width: 100px; height: 100px; overflow: scroll; display: grid;">
<div style="width: 0; height: 120px; outline: solid red;"></div>
<div style="width: 120px; height: 0; outline: solid green;"></div>
</div> |
|
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: css-overflow-3<fantasai> github: https://github.com//issues/4791#issuecomment-862553085 <TabAtkins> fantasai: If an element has zero area in its border box, it doesn't directly contribute to scrollable overflow <TabAtkins> fantasai: It can have indirect effects, if it increases the height of its parent box or something <TabAtkins> fantasai: But the element *itself* doesn't appear to do anything in impls. Should we add that to the spec? <TabAtkins> astearns: Seems reasonable <TabAtkins> florian: Yes, both because interop is good to spec, and because authors really hate when invisible boxes have side-effects <TabAtkins> astearns: Would be great to have these tested properly too <TabAtkins> astearns: So proposed resolution is to specify that zero-area border-box elements do not directly contribute to scrollable overflow area <TabAtkins> astearns: Objections? <TabAtkins> RESOLVED: Elements with a zero-area border-box do not directly contribute to scrollable overflow area. |
|
@bfgeek Edited into https://drafts.csswg.org/css-overflow-3/#scrollable |
|
@fantasai Is there anything left with this issue? |
|
@MrHBS No, just wanted to ask @bfgeek to sign off that the edits are correct. |
It appears that, at least in some implementations, zero-width elements do not contribute to the horizontal overflow, but zero-height elements do contribute to the vertical overflow.
So overall it seems that zero-sized things contribute in the block axis but not the inline axis.
This is kinda weird, but if it's required for Web-compat we should spec it.
The text was updated successfully, but these errors were encountered: