Re: Specifying the association with an online timing service

"On[c]e you switch to an asynchronous mode of execution, you can't (and
thus shouldn't) make any assumption about the order and timing of async
operations".

Exactly - not being able to make such assumptions increases the work load
on the consumer/programmer (effectively having to sort out the actual
ordering in code)

We are instead proposing to allow programmers to safely make this
assumption thus easing their work (by effectively transferring the
responsibility of sorting it out to the interface implementation).

Ingar


2015-06-10 14:05 GMT+02:00 Dominique Hazael-Massieux <dom@w3.org>:

> On 10/06/2015 12:53, Njaal Borch wrote:
>
>>
>> The attached test does work, as it hooks everything up before the video
>> element becomes ready.
>>
>
> Right; this is what I was illustrating — code sequenced in a single
> execution task can't have underlying state changed under its feet.
>
>  Try adding a setTimeout around it, like:
>>
>
> Right; but setTimeout precisely creates a separate execution stack, in
> which case the JavaScript semantics I was alluded to no longer apply (by
> design, otherwise asynchronous code would be useless).
>
>         setTimeout(function() {
>>        var v = document.getElementById('v');
>>        v.addEventListener('canplay', function() {
>>          document.getElementById('log').textContent = 'ready to play';
>>        });
>>      }, 1000);
>>
>> Actually, with just 100ms delay, my FF often does not emit the event,
>> one second delay and it never does.  Chrome mostly emits it with 1s
>> delay, never with 2s...  FF is particularly faster on reloads, clearly
>> caching some data. So if you want to get the event consistently, you
>> will have to register for the canplay listener early enough.  There are
>> of course solutions (be faster, do the check and emit yourself), but we
>> can do this consistently by replaying the event on addEventListener. :-)
>>
>
> One you switch to an asynchronous mode of execution, you can't (and thus
> shouldn't) make any assumption about the order and timing of async
> operations.
>
> Dom
>
>
>