[css3-positioning] position:sticky algorithm currently prefers bottom over top, and right over left

[stephenmcgruer]

Spec section: https://www.w3.org/TR/css-position-3/#sticky-pos

Currently Chrome, Firefox, and (I believe) Safari implement position: sticky such that when 'top' and 'bottom' conflict, the 'top' value wins (e.g. the element will be pushed down rather than up in such a case).

However this behavior is not backed (as far as I can tell) by the algorithm in the spec. The algorithm instructs the UA to first move the sticky down for the 'top' value (step 3), and then move the sticky up for the 'bottom' value (step 4). This would actually mean that 'bottom' overrides 'top' (and 'right' overrides 'left' similarly).

I suspect that this is behavior that is meant to be covered by Issue 2 (at time of writing): "Say what happens if this rectangle is empty". The 'rectangle' here is the inset rectangle created from the flow box rectangle (e.g. created from the scroller), and I believe the issue should instead read 'Say what happens if this rectangle is smaller than the position: sticky element'. The latter is precisely the case where we will have conflict between some properties, and need to specify which one wins.

So imo we should both correct the issue text, and then actually fix the issue by specifying which property wins :)

[flackr]

Specifically though I believe we would want to say the block and inline direction constraints have priority.

[FremyCompany]

cc @gregwhitworth

[fantasai]

I haven't looked into the position: sticky spec yet, but I'm 100% sure that if we're picking a winning side, it should be responding to the writing mode, like it does for all the other position values according to CSS2.1 chapter 10.

[jonjohnjohnson]

@stephenmcgruer From what I can see, chrome/firefox prefer top if sticking of both edges can't be met, but safari uses each conflicting edge based upon the in-flow position being beyond that edge and scrolling between the difference when in-flow crosses through the scrollport.

-> http://jsbin.com/zuwikov/

If both edges are set and don't conflict chrome/firefox/safari stick both edges simultaneously...

Sticky elements stick to both edges -> http://jsbin.com/zuwikov/4
Sticky elements fill scrollport and stick to both edges -> http://jsbin.com/zuwikov/3

I'm 100% sure that if we're picking a winning side, it should be responding to the writing mode

Blink does in fact respond to direction/writing-mode in picking the winner of conflicting offsets, for both inline and block directions.

Updated

[FremyCompany]

Edge renders exactly like Chrome in this case. Both values are used simultaneously.

[jonjohnjohnson]

Nested elements with position:sticky seem to have interop issues regarding box offsets conflicts. Blink "creates" a conflict between top and bottom when nested. Firefox and Safari do handle nesting "correctly", even if firefox has severe paint issues. Surprisingly, iOS Safari is smooth here. I'm not sure about Edge, the testing I use cannot handle it.

Example -> .page-panel top and bottom
http://output.jsbin.com/zeyanef/7

PS If anybody can explain the example layout structure in plain english, please do.

[jonjohnjohnson]

Chrome bug filed -> https://bugs.chromium.org/p/chromium/issues/detail?id=841432

[jonjohnjohnson]

Even more web compat when there are conflicting box offsets alongside margins that offset the sticky elements in-flow position back to the edges of the scroll container.

http://jsfiddle.net/78oamb6u/53/

• firefox and chrome only stick to the top
• chrome doesn't ever move the sticking element fully into view, because of negative margin
• firefox creates extra overflow as you scroll and moves the sticking element once reaching the height of the sticking element.
• safari, again, splits the difference and "interpolates" the sticking position between offsets based upon scroll position. This, in effect, offers inverted scrolling.

.el {
  position: sticky;
  top: 0;
  bottom: 0;
  height: 1000px;
  margin-bottom: -1000px;
  margin-top: -1000px;
}
.el::before,
.el::after {
  height: 1000px;
}

I know the spec doesn't currently have an editor and you guys seem to be more or less hands off, having implementors discover some emergent parity, but I think a bit of direction from the group could help stabilize.

[tabatkins]

We rewrote the stickypos text, and as far as I can tell this issue was fixed as part of that. Let me know if there are still any issues!

[fantasai]

CC @jonjohnjohnson for review :)