RE: [css-position] Sticky positioning computations

> -----Original Message-----
> From: Viatcheslav Ostapenko [mailto:sl.ostapenko@samsung.com]
> Sent: Monday, March 3, 2014 2:24 PM
> 
> > On Sun, 2014-03-02 at 20:58 +0000, Rossen Atanassov wrote:
> >
> > 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.
> 
> I think if sticky element overflows the containing box, sticky positioning
> shouldn't apply and sticky element should stay on its normal flow position. 

I would agree with that.

> > - Should the ReleasePosition be computed any differently if the
> > ContainingBox is also the ScrollerBox?
> 
> Does it makes sense to have sticky positioning if container box is itself scroller
> box? If there is no use case, I would suggest just disallow sticky positioning if
> container box is scroller box and fall back to normal flow.

I can certainly see use cases for that. Headers followed by paragraphs of text
is one such scenario where an author might want to make the headers sticky.

> > - Should the StickyPosition apply if the static StickyBox.top is already above
> > initially?
> 
> I think yes. For example, table header in the middle of long list.

OK, but what that would mean is that a the box will "jump" to the sticky position
and get stuck there. Consider the following scenario:

<div style="overflow: scroll; height: 5em; width: 5em;">
  <div style="border: 1px solid blue">
    <div style="position: sticky; top: 0px; margin-top: -2em; height: 4em"></div>
  </div>
</div>
 
> > - Should the StickyPosition apply if the ReleasePosition is above it initially?
>  
> I think yes, especially for cases when StickyBox is still visible in the scroller
> box.

If that happened then such an element will be stuck (since the release position
is already passed). I'm not sure this is very different than the scenario above.

Thanks,
Rossen

Received on Wednesday, 5 March 2014 22:37:49 UTC