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

On 30/11/2012, at 12:08 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

>> 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 get a huge amount of complaints from users over scrolling
performance, on sites that don't do any of this advanced stuff.
Simon mentioned how easy it is to fall onto a slow path.

Maybe you've only seen complaints from developers? 

> 
> We can't put this genie back in the bottle, nor do we *want* to -

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

I think it's slightly troublesome that this is adding interactivity to
CSS, but doing it through a back door. You're basically saying that
CSS will control the state of the document based on what the user is
doing. With the exception of :hover, that's a significant change to
the design goal of CSS. And if we're adding responses to interaction,
why is this particular limited feature the most essential? I would think
the most obvious starting point for such an adjustment to CSS would be
having a selector match based on the state of non-related elements
(i.e. click on something and another part of the page changes state). But
anyway, I'm saying that this proposal is making a big change in the 
CSS model.

Also, I'm skeptical that your proposal is really any easier for
authors beyond the most simple cases. Highly interactive things
are often better done in script. The prior art you show are fairly
cool demos, but very linear.

For example, your proposal mentions the pull-to-refresh. If you look
at the iOS implementation of the system PTR, you'll see this is something
that couldn't be done without script (a graphic that changes shape as the
rubber band is pulled).

But mostly, I really don't think this is important to the Web and
the CSS community right now. We're having to conduct polls of the CSS WG
members to decide which small subset of the huge amount of work that
needs to be done will actually get any attention. Is this more important
than everything we won't get to?

I'd like this group to focus on

(a) things that can't be done but are necessary/highly-desired (responsive
    gradients is a good example), or
(b) fixing the existing things that people are using

Compare your proposal to the position:sticky one. This is something related
to scrolling that was addressing a clear need and helped both users and
developers.

I think the phrase I'm looking for is "bang for buck".

Dean

Received on Friday, 30 November 2012 12:14:14 UTC