Re: [timingobject] Is timeupdate event necessary?

Frequency would be nice, but custom versions can easily be built as 
you
suggested, so I think keeping the addEventListener signature is 
perfectly
fine if there is no opening for custom options.


---
Dr. Njål Borch
Senior researcher
Norut Tromsø, Norway

On 23 August 2015 at 21:30, Ingar Arntzen <notifications@github.com> 
wrote:

> Njål Borch replied in
> 
http://lists.w3.org/Archives/Public/public-webtiming/2015Aug/0025.html
>
> "In regards to 2), why would time update be chained? I presume the 
code in
> 1) or equivalent could easily be included into the timing object 
itself, so
> nodes generate timeupdate events on subscriptions. They are not 
inherited,
> hence there is no need for a transformation. The timeupdate event is
 very
> convenient, if only to limit the amount of cut'n'paste code that 
people get
> wrong."
>
> Hm. Maybe it doesn't after all. In my mind the timeupdate event 
included a
> state vector - which would then have to be transformed in a chain. 
However,
> if we simply say that there is no vector included - then the problem
> evaporates :)
>
> If we were to include this logic into the timing object, it would be
 nice
> to support custom frequency by parameter.
> .on("timeupdate", handler, 100)
> I suppose this would be inconsistent with the classical 
addEventListener
> signature? Is there any way around this?
>
> —
> Reply to this email directly or view it on GitHub
> 
<https://github.com/webtiming/timingobject/issues/15#issuecomment-133908082>
> .
>


-- 
GitHub Notif of comment by Snarkdoof
See 
https://github.com/webtiming/timingobject/issues/15#issuecomment-133909002

Received on Sunday, 23 August 2015 19:36:44 UTC