W3C home > Mailing lists > Public > www-style@w3.org > August 2013

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

From: Robert O'Callahan <robert@ocallahan.org>
Date: Thu, 29 Aug 2013 10:47:13 +1200
Message-ID: <CAOp6jLbuTqguFmt3jXV1enhrz5U=Z2FmJs1eMWgdq4_tECngGA@mail.gmail.com>
To: Simon Fraser <smfr@me.com>
Cc: Ojan Vafai <ojan@chromium.org>, Corey Ford <cford@mozilla.com>, "www-style@w3.org" <www-style@w3.org>, "L. David Baron" <dbaron@dbaron.org>
On Thu, Aug 29, 2013 at 8:04 AM, Simon Fraser <smfr@me.com> wrote:

> 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.

You could make the "stuck" state apply lazily, so scrolling wouldn't
stutter but a shadow (for example) would not appear or disappear

You could also implement it "properly" by sending two versions of the
element to the compositor thread: one drawn in the stuck state, another
drawn not in the stuck state, and let the compositor pick which one to sue.
That would be somewhat horrible to implement though.

Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
Received on Wednesday, 28 August 2013 22:47:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:33 UTC