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

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

From: Simon Fraser <smfr@me.com>
Date: Thu, 29 Nov 2012 16:51:04 -0800
Cc: Rik Cabanier <cabanier@gmail.com>, www-style list <www-style@w3.org>
Message-id: <AB038919-15C9-472C-8609-6B861A09D3D3@me.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
On Nov 29, 2012, at 4:07 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Nov 28, 2012 at 9:12 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Wed, Nov 28, 2012 at 8:23 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>>> Can you explain how your image carousel works?
>>> Specifically, how are the animations on the images triggered and
>>> synchronized by the timeline?
>> I'd been thinking something was "off" when I put that example
>> together, and I was right - it's completely wrong, actually.
>> To do that example correctly, you need a separate @keyframes rule for
>> each element, which properly moves it to the end, then flips to the
>> beginning, and finally ends back at its starting location.  These will
>> vary for every one, because they're all different distances from the
>> end.
> Never mind, I found a better way to do it.  It still requires work
> per-item, but only in the form of individual 'animation-delay'
> properties.  You only need a single @keyframes now.  It's updated in
> the doc.
> I also reworked the syntax a little bit.

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.

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.

Received on Friday, 30 November 2012 01:52:45 UTC

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