W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: Request for Comments: Proposal for Touch-Based Animation Scrubbing

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 30 Nov 2012 10:53:25 -0800
Message-ID: <CAAWBYDBXG-NgjPCOo_3zXonzh9a-mMd3BtbjZkQKSDifXd=pZA@mail.gmail.com>
To: Simon Fraser <smfr@me.com>
Cc: Rik Cabanier <cabanier@gmail.com>, www-style list <www-style@w3.org>
On Thu, Nov 29, 2012 at 4:51 PM, Simon Fraser <smfr@me.com> wrote:
> I'm deeply suspicious of features that will add more complexity to scrolling.
>
> I think scrolling is really something that needs to be under user control,
> which few or no side-effects on the page (other than simple declarative
> things like position:fixed and sticky). We're spending a lot of effort in
> WebKit to make scrolling as smooth as possible, and features that
> complicate the scrolling logic will likely cause us to fall off the fast path,
> which results in a poor experience for users.
>
> I understand that the intent of your proposal is to allow UAs to optimize
> scrolling-related mutations of the page content. I think the reality is that
> it adds such complexity to the scrolling implementation (something
> that is already very different across different platforms) that many platforms
> will just fall back to the "slow" implementation, and users will remain unhappy.

To be more specific (and to echo something Francois already said), I
think this fear is completely unfounded.

Currently, we all do some variety of fast scrolling when we can, and
de-optimize in some conditions, one of which is the presence of a
scroll listener on the element being scrolled.  This is necessary,
because we have no idea if the JS is just piggybacking on the
scrolling, or if it's actually co-opting it and will call
e.preventDefault().

If we assume a browser like the above which implements my proposal but
puts zero effort into optimization, then, in the WORST CASE, it will
just de-optimize scrolling *on that element*.  Your fear that they'll
just give up and de-optimize the entire page seems ridiculous, as we
know declaratively which elements are co-opting scrolling.  So, worst
case, the author gets the same performance as doing their thing in JS,
but an easier declarative syntax.

In the expected case, browsers will use the declarative knowledge to
do an end-run around JS, and do the animation in an extremely
responsive and smooth manner.  That's the point of this proposal.

~TJ
Received on Friday, 30 November 2012 18:54:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:03 GMT