- From: jonjohnjohnson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Nov 2018 18:07:53 +0000
- To: public-css-archive@w3.org
jonjohnjohnson has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-position][css-position-3] Padding on scroll container affects (and inconsistently) the offset behavior of sticky position == 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 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3352 using your GitHub account
Received on Wednesday, 28 November 2018 18:07:54 UTC