Open Bug 1441134 Opened 6 years ago Updated 2 years ago

scrolled flexbox container doesn't account for content's margin

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

People

(Reporter: kamac2495, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

Create two elements, one nested in the other. Set the first one to fixed dimensions, display: flex and overflow-y: auto. Set the nested element's style to be of height greater than the parent container, and have a margin-bottom greater than 0 px.

Relevant pen: https://codepen.io/anon/pen/NyOzbo


Actual results:

When scrolled to the bottom of the element, there was no visible margin from parent's bottom.


Expected results:

There should be visible margin to the bottom of scrollable element. (Like padding in scrollable display: block would behave)
Firefox is actually matching the spec's requirements here. The spec (unfortunately) gives some wide flexibility as to what should be included in the scrollable overflow (i.e. how far the scrollbar should let you get).

You're asking for the *margin box* of the child to be scrollable, and the spec *allows* that behavior, but does not require that. Spec link: https://drafts.csswg.org/css-overflow/#scrollable-overflow-region

Select quotes:
> The scrollable overflow region is the union of:
>  -  the box’s own content and padding areas
>    [...]
>  - the border boxes of all boxes for which it is the containing block

(note: "border boxes", not "margin boxes")

And then there's this afterthought:
> The UA may additionally include the margin areas of boxes for which it is the containing block.
> The conditions under which such margin areas are included is undefined in this level.
> This needs further testing and investigation; is therefore deferred in this draft.

Firefox is opting not to include the margin area of the child boxes here.  Based on the vagueness of the spec, I'm guessing there are cases where that'd be good and cases where that'd be bad, and the spec editors haven't sorted them out yet.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
(Sorry, didn't mean to mark this as a duplicate after all -- that was an initial guess before I wrote comment 1, and I forgot to clear the duplicate field before hitting submit. :))
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Status: REOPENED → NEW
Component: Untriaged → Layout
Product: Firefox → Core
Version: 58 Branch → Trunk
[Triage 2018/03/23 - P3]
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.