Re: [web-animations] Web Animations minutes, 12 Mar 2014

(2014/03/12 18:36), Dirk Schulze wrote:
> On Mar 12, 2014, at 10:18 AM, Brian Birtles <bbirtles@mozilla.com> wrote:
>
>> Background research: http://jsfiddle.net/6SudQ/1/
>> Is it ok to drop events? Firefox, Chrome, Safari: Do (for CSS Animations), IE: Doesn't
>> Developing for mobile is harder if events are dropped. On the other hand, forced dispatch of events is bad for mobile too.
>>
>> CSS Event usage stats from Chrome:
>>   Start 0.06% http://www.chromestatus.com/metrics/feature/timeline/popularity/131 (600 ppm)
>>   Iteration 0.002% http://www.chromestatus.com/metrics/feature/timeline/popularity/134 (20 ppm)
>>   End 0.37% http://www.chromestatus.com/metrics/feature/timeline/popularity/128 (3700 ppm)
>
> Well, the comment above says that Chrome and Safari do drop events but then there are user stats of interface calls? I think certain evens like start and end (firing in time to run JS code for the next frame) can be very useful. Others might not.
>
> Maybe this should also be discussed with the wider CSS/SVG group? The discussion wouldn’t/shouldn’t block a new WD though.

Hi Dirk,

Sorry, the minutes here were prepared more hastily than usual and are 
quite misleading.

1) "Dropping" above refers to the situation where a UA should dispatch 
100s or 1000s of events within a very small time window. The above 
fiddle shows that in this situation Firefox, Chrome, and Safari do *not* 
dispatch all the iteration events in that situation. IE does but it also 
doesn't allow animation durations < 0.01s which mitigates this somewhat.

2) The usage statistics were an entirely unrelated point trying to 
determine the sorts of use cases for which events are used.

So we are definitely *not* proposing removing animation/transition 
events from CSS. Rather, we have been looking at how events should work 
from the API.

Originally I wanted to define some common event model and then define 
CSS and SVG animation-related events in terms of that model. We ran into 
lots of difficulties there including the whole "certain arrangements 
could lead to dispatching 1000 events per sample, especially only mobile 
devices."

We decided instead to make events in the API incredibly simple by only 
providing a finish event for players. CSS/SVG events do not change. I 
added this to the ED yesterday.

We *also* looked at being able to support trigger-style use cases where 
the author wants to say, "When you reach this point in the scene graph, 
run this operation (pre-fetch a resource, do DOM manipulation etc.)."

In the minutes we talked about defining the situations in which custom 
effects (callback functions) get evaluated such that you can use them 
for this sort of use case. Yesterday we revisited this since there was 
some concern that this was not ideal (the callback would need to check 
current direction and various other properties to provide correct 
behaviour).

The outcome we reached was to *not* add special handling to custom 
effect callbacks for this situation. It's still possible to use custom 
effects for triggers but it's more tricky. We will either revisit this 
decision or provide a Trigger primitive later if necessary. In any case, 
custom effects are not likely to be shipped for quite a while so there's 
no urgency on this point.

I hope that clarifies the misleading minutes. Sorry about that.

Best regards,

Brian

Received on Thursday, 13 March 2014 23:13:04 UTC