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

On Fri, Nov 30, 2012 at 4:13 AM, Dean Jackson <dino@apple.com> wrote:
> 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?

This is an irrelevant point.  If authors implement the functionality
in this proposal themselves with JS, they'll trigger *at least* as
much de-optimization, but their performance will be noticeably worse.


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

Given the prevalence of this kind of pattern on native apps, and the
increasing prevalence in the web despite the pain and crappiness (see
my Prior Art section, which is only a sampling of all the stuff out
there that could benefit from this), I don't think it's realistic to
pretend we can do so.

Avoiding the work to make touch-based interfaces work well in browsers
will just mean that webapps will continue to perform worse than native
apps in this important UI aspect.

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

I appreciate that there are *multiple* places where we need to add
more interactivity into CSS.  (More properly, we need to add more
declarative interactivity via *some* mechanism, and CSS is the easiest
way to attach declarative data to elements at hand.)

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

You are correct that my listed examples are relatively simple.  I
believe that they're representative, though - most such touch
interactions are fairly simple and linear.  The examples are drawn
from actual usage, after all; they're not just made-up trivial
showcases of the syntax.  You would *actually* be able to use my code
for the Twitter pull-to-refresh, for example.

Note, though, that "linear" might not be accurate.  You can certainly
utilize transforms (even 3d transforms) in the proposal to achieve
very fancy effects.  For example, the ubiquitous 3d transform demo of
the ring of numbered panels is easy (just a light modification of the
carousel demo code I already have), and would make a cool way to
present a slideshow!

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

I have no idea what this is, and google isn't helping - can you point
to images or a video of it working?

Regardless, I'm comfortable with very advanced cases not being able to
use this, as long it solves a large majority of actual case.

That said, shape-warping isn't actually out of the picture.  This
proposal slots nicely into the Web Animations proposal, which means
you should be able to link up the scrubbing controls to SVG
animations, such as <path> animation.

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

It is currently *impossible*, not just hard, or doable if you have
enough engineering resources, but *impossible* to create an app that
responds to touch the same way that a native app does.  You can't work
around the delay imposed by having the touch get translated into a
gesture and stroll its way into the JS event queue, and it's not
uncommon for this delay to be 100ms.  Worse, once you *do* start your
late response to the gesture, you're at the mercy of the UI thread,
which janks when you look at it funny, so your motion will often be
jerky if any other JS happens to be running at the same time,
particularly if you're on mobile.

If you feel that the problems I'm trying to solve aren't worthwhile,
that's cool.  We can debate about that.  But this isn't a frivolous
feature; it's addressing a place where there is something missing in
the current platform that authors are unable to plug themselves.

~TJ

Received on Friday, 30 November 2012 21:36:29 UTC