Re: :stuck psuedo class WAS: specifying position:sticky

On Aug 27, 2013, at 5:34 PM, Ojan Vafai <ojan@chromium.org> wrote:

> This may be too early, but I think we should add a pseudo-class for position:sticky's that are stuck to an edge. This lets you easily style the stuck element (e.g. with a box-shadow).
> 
> 
> On Tue, Jul 23, 2013 at 6:19 PM, Corey Ford <cford@mozilla.com> wrote:
> On 7/12/13 9:37 AM, Corey Ford wrote:
> For any of 'top', 'bottom', 'left', and 'right' that are not 'auto', if the box's normal position would cause that edge of its margin box to be less than the specified distance within that padding edge of its scrolling container, the box is repositioned to that distance from the edge
> 
> Percentage values of these properties reference the padding box of the scrolling container.
> 
> The content box of the scrolling container would also be reasonable at these points in the calculations. (I'm not entirely sure what I see WebKit doing, but it doesn't seem to be either.)
> 
> Corey

We considered a pseudoclass like this, as it’s common to see sites changing the style of an element when it drops into the “stuck” state.

The problem is that it defeats one of the main optimizations which drove our creation of a declarative sticky behavior, which is that we want to be able to delegate the implementation of the sticky behavior to another thread, the thread on which scrolling happens (keeping it off the main thread means that scrolling can remain responsive even when the main thread is busy doing layout/painting). If we have to do layout when an element enters or leaves the sticky state, then we’ll have to do that back on the main thread, which would result in a scrolling stutter.

Simon