The spec is fine wrt. to this IMO. The margins aren't directly added to the scrollable overflow - rather the margins are affecting the inflow-bounds:

"Additional padding added to the end-side of the scrollable overflow rectangle as necessary to enable a scroll position that satisfies the requirements of place-content: end alignment."

The test there isn't testing at we add the margins directly to the scrollable overflow.

There is an open question if we need the to add margins (directly) at all now, from feedback we've received about the "additional padding" change it isn't, and this matches developer expectations.

Currently Gecko/WebKit aren't actually following the spec here adding margins in all cases for example:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11464
(If margins were being added directly there'd be overflow in that test).

(Gecko is doing this in a somewhat broken manner for block containers however, e.g. when margin-collapsing is present - https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11465 )

Instead Gecko/WebKit are only doing this if it is a flex/grid container is a "scrollable container" as well.
The difference here is super sutble - but likely isn't needed anymore since we perform the "additional padding" now.

Thoughts?

Ian

@dshin-moz - https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11469 Gecko is only doing the weird treatment in one axis as well.

The spec is fine wrt. to this IMO. The margins aren't directly added to the scrollable overflow - rather the margins are affecting the inflow-bounds:

"Additional padding added to the end-side of the scrollable overflow rectangle as necessary to enable a scroll position that satisfies the requirements of place-content: end alignment."

I don't think it's well-defined what it means to satisf[y] the requirements of place-content: end alignment, though. To the extent that it is well-defined, it seems the spec says to do nothing in this case.

The axis we're discussing here is the inline axis of a block container, which would correspond to the justify-content subproperty in the spec's hypothetical place-content:end expression.
And the definition of justify-content says:
justify-content Axis | Does not apply to and has no effect on block containers

(There's some nuance for scroll-container-specific behavior in css-align-3 section 5.3, but that still ties back to "the expected alignment of the alignment subject and alignment container", which in this case is "no effect", per the "does not apply" quote above)

So AFAICT justify-content:end is defined as having no effect on block containers, regardless of whether they're scrollable.

So we might need to rewrite what this place-content reliance is supposed to mean, or adjust css-align-3 section 5.3 to make it clearer what's supposed to happen w.r.t. the initial scroll position for containers-that-are-unaffected-by-justify-content.

@dshin-moz - https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11469 Gecko is only doing the weird treatment in one axis as well.

Haven't looked closely at this yet, but if it's relevant, we haven't landed our changes for #129 yet (https://bugzilla.mozilla.org/show_bug.cgi?id=1768921 ).

I don't think it's well-defined what it means to satisf[y] the requirements of place-content: end alignment, though. To the extent that it is well-defined, it seems the spec says to do nothing in this case.

Yeah I'd probably agree with that. I previously advocated for writing down the "inflow-bounds" for each layout method - but I think others said the place-content: end alignment was equivalent to this.
#129 (comment)

Haven't looked closely at this yet, but if it's relevant, we haven't landed our changes for #129 yet (https://bugzilla.mozilla.org/show_bug.cgi?id=1768921 ).

The main thing to keep in mind is that this isn't directly adding margins, just the padding at the end of the inflow-bounds.

@dholbert - What do you think of removing the margin-clause entirely?
E.g. For flex/grid items, firefox&webkit are only applying the margins if the grid/flex container is also a scroll container, and since we have the inflow-bounds padding-edge, its applicability is very limited now (need to create very complex cases to actually trigger the behavour difference).