[css-position][css-position-3] Padding on scroll container affects (and inconsistently) the offset behavior of sticky position

[jonjohnjohnson]

IMHO padding on the scroll container shouldn't even be affecting offset behavior of what authors think of as the "edge" of the scroll container, but since it does, then it should be doing so consistently, or at least documented.

https://drafts.csswg.org/css-position-3/#sticky-pos
https://bugs.chromium.org/p/chromium/issues/detail?id=814141#c_ts1524700607

Test Case - http://jsfiddle.net/jonjohnjohnson/eagx28jp/

Why aren't all three of the vertical scrollers in the example spec'd to to exhibit the same sticky offset when using the same box offset values?

The chromium issue provided above even shows blink deciding to go with interop of this strange/unspecified behavior.

• The right scroller shows padding on the body not affecting offset.
• The middle scroller shows padding affecting offset.
• The left scroller shows padding on an element inside the scroller not affecting offset.

I'm guessing this is because of the age old quirk of padding on scroll container rarely being intuitive or consistent? And here, though body (or even if you change the selectors that match body to html, then html as well) has the non-zero padding, it doesn't keep its geometry in place as its content scrolls through, unlike other scroll containers? In other words, the left and middle scrollers.

If this is the desired behavior/interop, we at least need it communicated clearly in the spec.

cc @atanassov @arronei @stephenmcgruer

[Loirooriol]

It seems to me this is according to the spec.

The right scroller shows padding on the body not affecting offset.

That's because the padding applies to the body, but overflow applies to the viewport, according to https://drafts.csswg.org/css-overflow-3/#overflow-propagation. And the viewport has no padding.

You can use non-visible overflow in the html to force body's overflow to apply to the body. http://jsfiddle.net/kc5pzx40/

The middle scroller shows padding affecting offset

I think this is expected, because the containing block of a sticky element is the same as for a relative element. So it uses the content area of an ancestor, and not the padding area.

The left scroller shows padding on an element inside the scroller not affecting offset.

That's because when you scroll down, the inner wrapper moves up, and the scrolling container stays where it is. So when you scroll past the padding, the sticky-constraint rectangle ends up anchored at the top of the scrolling container.

[jonjohnjohnson]

You can use non-visible overflow in the html to force body's overflow to apply to the body.

When succumbing to using this, you often lose viewport scrolling benefits of certain browsers, like scrolling making the visual viewport larger on iOS or clicking the top bar in opera to perform a "scroll to the top" action.

This may all be on the up and up as far as language deep within the specs, but I still stand by a need to more clearly document these behaviors in css-position-3 in regards to the description of box offset properties and content boxes from scroll containers. So people know what top: var(--fixed-header-height) would mean for them compared to top: calc(var(--scroll-container-padding-top) - var(--fixed-header-height)).

[jonjohnjohnson]

Funnily enough, this gets slightly more convoluted when using scroll-padding to adjust the optimal viewing region alongside sticky positioned elements that might be targeted for scroll anchoring/snapping purposes, depending on the scrollport having padding as well.