- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 18 Sep 2014 12:31:56 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Timothy Dresser <tdresser@chromium.org>, DOM public list <www-dom@w3.org>, Rick Byers <rbyers@chromium.org>, Nathaniel Duca <nduca@chromium.org>
On Thu, Sep 18, 2014 at 11:44 AM, Jonas Sicking <jonas@sicking.cc> wrote: > On Thu, Sep 18, 2014 at 10:00 AM, Timothy Dresser <tdresser@chromium.org> wrote: >> Is there any interest here in discussing an API like this? We expect that >> the API specifics will evolve significantly as we start to experiment with >> an implementation and receive feedback. > > I'm very concerned about anything that forces us to do a main-thread > roundtrip in order to enable scrolling. I thought Google shared this > concern as this had been given as one of the big reasons for not > supporting pointer events. > > I'd rather look at things like animations that use scroll or touch > position as a time source and enabling people to build these features > that way. We do share this concern, and support further development of things that make off-main-thread scrolling more useful, such as the Scrolling Through Time stuff that Apple just re-proposed (an idea whose time has come, I guess ^_^). But, ultimately, there's only so much power you can offer declaratively. Eventually you need to write a feature that lives on the main thread but interacts with scrolling, such as stickypos, and has behavior that can't be adequately captured by the existing mechanisms. We want to be sure that there's an escape hatch for authors to reach for in these cases. We don't expect them to be common, and we hope that further declarative developments will make it rarely necessary, but just declaring that these kinds of unserved use-cases just have to live with jitter and jank isn't acceptable. ~TJ
Received on Thursday, 18 September 2014 19:32:47 UTC