- From: None via GitHub <sysbot+gh@w3.org>
- Date: Sun, 23 Aug 2015 19:36:42 +0000
- To: public-webtiming@w3.org
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