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

[Tab Atkins Jr.:]
> 
> On Fri, Nov 30, 2012 at 2:15 PM, Sylvain Galineau <sylvaing@microsoft.com>
> wrote:
> > At this point in time, I'll second this sentiment; should the recent
> > poll be run again I wonder where this would land. There are so many
> > things people write script for that could be done declaratively. The
> > value of doing so is, however, very unevenly distributed.
> 
> I knew I should have objected harder to the prioritization poll. I
> *knew* it would be used for stop energy, and it's been doing just that for
> a little while already.

Nobody stops you or Google from experimenting however you want. Just like 
nothing stops Microsoft from adding experimental scrolling, zooming or 
panning properties in its own namespace. If you guys have the 'energy', 
then by all means go do it.

That we, as a group, must prioritize our time in order to make progress 
on the dozens of documents we have started is just unavoidable. It's just
reality. It doesn't in any way prevent Google or anyone else from pursuing 
their own priorities as they see fit.

> 
> It was stated, early and emphatically, that the prio list was *solely* for
> the purpose of helping us answer, with a smidge of objectivity, which
> things we should talk about *in telcons and meetings, when we have too
> much to discuss in the time available*.  I and other people (dbaron, I
> think?) were concerned that it would be used to shut down work on "low
> priority" things, and we were assured that it would not be.  Surprise
> surprise!

My feedback at this time would have been the same with or without a 
poll, Tab. Again, you can do whatever you want. You can ask for as 
much input on this list as you want and people can provide as much 
or as little as they wish. And said feedback may well include upfront 
statements by other members that such scenarios are not a priority 
for them, *and* that they don't believe it should be a priority for 
the group  either. You may not like to hear the latter, and you may 
attempt to minimize such feedback by arguing over the semantics of 
what 'having priorities' should mean, or what one particular poll 
was intended to achieve. The feedback stands.
 
> 
> > In fairness I am certainly not opposed to CSS work in the general
> > areas of scrolling, panning or zooming; we did plenty of that for
> > Windows 8 and it resulted in new CSS properties [1] e.g. to specify
> > 'snap points' when panning through a bunch of images or other elements
> (which slightly overlaps with some of your scenarios).
> > These features proved quite useful in building good experiences -
> > especially for touch users - and they likely perform orders of
> > magnitude better than whatever could be scripted to emulate them. So I
> > agree there are declarative steps we can take to make it easier to
> > build good touch interactions; but we could and imo s hould start with
> > simpler, broadly usable solutions before moving on to more elaborate
> effects where developers control every millisecond of what happens.
> 
> Could you explain how my proposal falls into "elaborate effects where
> developers control every millisecond of what happens"?  Again, if you
> don't think the effects I listed in Prior Art and similar common effects
> are *worthwhile* to address, that's fine.  But my proposal is not
> elaborate or complicated - if you ignore the momentum/snap points part,
> it's literally *two properties*, and one of those is just to hook things
> together.

Ah, it's only two properties. Well, z-index is one property so I suppose
painting order is cheap easy stuff? :) Animations can be quite elaborate, 
even complicated, and I don't see why we wouldn't expect elaborate animations
 to be hooked up to scrolling also. That you've only considered simple use-cases
or that it takes little code for the author to wire one feature to the other 
is orthogonal to the runtime cost and complexity of what they might actually 
do with this, really. 

Given our own scrolling, panning and compositing work I share some of the 
perf concerns voiced by others here. If a scroll gesture can trigger several 
animations - one or more of which might presumably affect layout - the 
resulting experience may be poor, especially on lower-end devices. So if 
the scenarios that would work reasonably well across devices were to be 
limited in practice, is what's left really worth the cost and extra complexity? 

Just because we already disable scrolling optimizations in similar situations 
today does not make it OK or desirable to enable the declarative creation of 
these suboptimal scrolling scenarios. That such an approach may suck noticeably 
less than the current state of the art for a relatively narrow set of simple 
use-cases is nice, but it's just not enough. The runtime outcome of a new
feature ought to align with the author's intent as often as possible. I fear 
that may be a real challenge to achieve here, at the moment. And I still 
believe there are many other problems we can solve around better touch 
experiences that would have a broader impact. (It goes without saying that 
I think some of the issues we've tried to work in Windows 8 have such appeal, 
but then I'd say that...)


> 
> (We should definitely make sure that the snap points/momentum stuff is
> consistent between this and normal scrolling.  Let's get on that Scrolling
> module, Sylvain!)

If there is group interest and bandwidth then it's certainly worthwhile.

> 
> ~tJ

Received on Saturday, 1 December 2012 04:04:07 UTC