RE: [css-position] Sticky positioning computations

> -----Original Message-----
> From: Corey Ford [mailto:corey@coreyford.name]
> Sent: Monday, November 25, 2013 10:43 PM
> 
> I'm happy to see position:sticky in a recent ED of Positioned Layout [1].
> However, I don't think the algorithm using a "sticky-constraint rectangle"
> accurately describes sticky positioning as outlined in my previous 
> draft text [2], and as I understand the Webkit and Gecko 
> implementations. The current issues 2 and 3 hint at this.

Agreed. The current definition of sticky is an initial stub based on notes Ted had sent me. I'm resuming active spec editing of positioning thus your feedback is great.

> The containing block and scrolling box influence sticky positioning 
> differently in that one creates a stronger constraint than the other, 
> so taking the intersection of two rectangles to create the 
> sticky-constraint rectangle isn't sufficient. Step 3 (and 4, 5, 6
> similarly) of the algorithm should read something closer to:
> 
> "If the stickily positioned element's 'top' style is not 'auto', and 
> the top of the stickily positioned element is above the top of the 
> scrolling container, the stickily positioned element is moved down 
> until its top is at the top of the scrolling container, or its bottom 
> is at or below the bottom of the containing block."
> 
> Notice that the bottom of the scroll container isn't taken into 
> account, nor is the top of the containing block. So top-sticky 
> elements can certainly extend past the bottom of the scroll container 
> (and those that are taller than their containing block simply won't ever move at all).
> 
> Gecko's implementation does use two rectangles based respectively on 
> the scroll container and containing block.
> 
> Thoughts?

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)

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.
- Should the ReleasePosition be computed any differently if the ContainingBox is also the ScrollerBox?
- Should the StickyPosition apply if the static StickyBox.top is already above initially? 
- Should the StickyPosition apply if the ReleasePosition is above it initially?

Thanks,
Rossen

Received on Sunday, 2 March 2014 20:59:00 UTC