flackr
commented
1 year ago
- Implementations (and the spec I think?) currently use border-box rect to determine if something is overconstrained (e.g.
position: sticky; left: 100px; right: 100px;. Is this intentional/correct?
I think this is correct, since margins are not maintained from the sticky view rectangle. For example, consider the following (demo):
<style>
.scroller {
height: 400px;
overflow: auto;
border: 1px solid black;
}
.sticky {
margin: 250px 0;
height: 200px;
position: sticky;
background: green;
top: 0;
bottom:0;
}
.spacer {
height: 200px;
background: #ccf;
}
</style>
<div class="scroller">
<div class="spacer"></div>
<div class="sticky"></div>
<div class="spacer"></div>
</div>The sticky element is not overconstrained. It can in fact be pushed up / down into the margin reserved between it and the adjacent spacers until it is 250px away from the top/bottom of the container / scroller. That said I still find it confusing that we try to preserve its margins from the container.
- Unclear from the spec how collapsing margins should be considered in the calculations above. Currently no implementations appear to look at collapsing margins.
IMO if we consider margins we should allow for them to collapse.
- The sticky view rectangle is currently defined as the border-box which seems to match what web-developers would expect. E.g. you don't expect the sticky-element to stick based on some unseen margin. Do the margins in the rest of the calculation add create more confusion than value? E.g. margins are often used for aligning content, if you use margins in this way and then make the element sticky-pos then it'll likely have un-expected behaviour (see auto-margins above as one example).
TL;DR Should the "position box" just be the border-box instead? (rather than the margin-box).
I agree, I think it would be simpler if the sticky adjustment were only constrained by the border box, and this might enable margins to be used to set the initial position. However, given that we seem to have compat on this part (with non-auto margins) there's a chance this will be breaking. In particular when the sticky element is first I could see developers being surprised if it gets pushed up into its top margin, or if last being pushed down into its bottom margin.
css-meeting-bot
dholbert
johannesodland
jonjohnjohnson
https://drafts.csswg.org/css-position-3/#stickypos-insets
The spec and implementations are currently a little scattered when it comes to how margins should be treated for sticky-pos elements. It's not clear if all the interactions have been thought through completely.
Implementations (and the spec I think?) currently use border-box rect to determine if something is overconstrained (e.g.
position: sticky; left: 100px; right: 100px;. Is this intentional/correct?Implementations currently differ on if auto-margins should be considered. For example: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11848
Per-spec Firefox is currently correct - however this might be surprising to web-developers as it'll effectively opt-out the element being sticky by default if they are just using auto-margins to center content.
Unclear from the spec how collapsing margins should be considered in the calculations above. Currently no implementations appear to look at collapsing margins.
The sticky view rectangle is currently defined as the border-box which seems to match what web-developers would expect. E.g. you don't expect the sticky-element to stick based on some unseen margin. Do the margins in the rest of the calculation add create more confusion than value? E.g. margins are often used for aligning content, if you use margins in this way and then make the element sticky-pos then it'll likely have un-expected behaviour (see auto-margins above as one example).
TL;DR Should the "position box" just be the border-box instead? (rather than the margin-box).