Re: [css-position] Sticky positioning computations

On 2014-03-02 21:58, Rossen Atanassov wrote:
> In general I agree with your definition. Here's the way I see the algorithm I just need to formalize it in prose. The following offsets the top position of a sticky box only and should be extended to all four sides of the sticky box. 
> 
> (assume origin is top left)
> ContainingBox is the containing element's content box bounds
> StickyBox is the border box of the sticky positioned box computed at its static position
> StickyPosition is computed from the nearest scroller box bounds minus top, right, bottom, left values of the sticky element (these props are used as additional padding away from the scroller box)
> ReleasePosition is computed from ContainingBox.boxx - StickyBox.height
+ StickyBox.Style.Bottom
> 
> IF ContainingBox.height > StickyBox.height AND ContainingBox.bottom > StickyBox.bottom  // don't apply sticky to boxes that overflow their container box
>   StickyBox.top = min(max(StickyBox.top, StickyPosition), ReleasePosition)

I think we get a nicer formulation by just writing:
StickyBox.top = max(StickyBox.top, min(StickyPosition, ReleasePosition))

That is, ReleasePosition isn't a limit on where the StickyBox can be,
only on how far sticky positioning can push it.

(Gecko's implementation works exactly this way, and I'm fairly confident
that WebKit's is consistent with it.)

> Here're some additional scenarios in the current spec that should be dealt with. 
> - When sticky box bounds exceed the containing box bounds due to size or overflow? Above I disallowed such scenario but this could be debated.

With the above change, this explicit check isn't necessary.

(However, per my previous spec notes, I think an "overconstraint" rule
that determines priority between top/bottom or left/right is appropriate
for too-large sticky elements.)

> - Should the ReleasePosition be computed any differently if the ContainingBox is also the ScrollerBox?

My intuition is that in this case the ReleasePosition should be based on
the size of the contents of the ScrollerBox (not its outer size).

WebKit appears to use the ScrollerBox's outer size, and Gecko currently
ignores ReleasePosition entirely, but is investigating using the size of
the scrolled contents:
https://bugzilla.mozilla.org/show_bug.cgi?id=915302

(And supporting this case is certainly useful, e.g. sticky toolbars or
sidebars, although often the ReleasePosition wouldn't matter there.)

> - Should the StickyPosition apply if the static StickyBox.top is already above initially?

Yes, and this is consistent with both implementations. Sticky
positioning doesn't depend on exactly where and when scrolling happens,
but is just a function of the scroll position, relative to the element's
position.

> - Should the StickyPosition apply if the ReleasePosition is above it initially?

Also addressed by my proposed formulation of the logic.

Corey