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: Thu, 29 Nov 2012 17:08:29 -0800
Message-ID: <CAAWBYDCmTuu4TvCDSX9rZPyKA-JWx10-LZvH8q1gPP8UMBDJZw@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.

This proposal was developed under the watchful eye of our own
scrolling/compositor people.  I'm assured that this is a reasonable
amount of effort for us, and will have a very large impact on our own
performance, relative to the techniques authors are using today to
accomplish the same things (see Prior Art).

> In addition, allowing authors to hijack a common user-interface feature
> like the scrollbar, and turn it into a knob that makes non-scrolling animations
> happen seems like something we don't want to encourage. Scrollbars are
> for users, not authors.

Scroll events, and their ability to cancel the actual scrolling and
hijack the deltas for the author's own purpose, already exist, and are
already commonly employed to do a lot of the effects I provided in the
Prior Art section.  This is not something new, nor is it something
that is going away, and I'm confident that its use will actually
continue to rise over time.

We can't put this genie back in the bottle, nor do we *want* to -
there's lots of genuinely good and useful things to be done in this
space, as demonstrated by all the prior art, both on the web and in
native apps.

This proposal just captures the common authoring patterns and make
them (a) easier for authors, and (b) less sucky for users.

Received on Friday, 30 November 2012 01:09:17 UTC

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