W3C home > Mailing lists > Public > public-webtiming@w3.org > June 2015

Re: Observing state and changes

From: Francois Daoust <fd@w3.org>
Date: Thu, 11 Jun 2015 13:50:41 +0200
Message-ID: <55797611.80103@w3.org>
To: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>
CC: public-webtiming@w3.org
On 2015-06-11 12:39, Ingar Mæhlum Arntzen wrote:
> Hi. Francois
> I agree about the concern that this breaks convention. I don't think it
> violates any code practices though. As long as the user agent triggers
> that initial event by using the event queue - registering a handler will
> not have any (synchronous) side effects. When you register a handler you
> must always expect that it may fire an event asynchronously at any time,
> so event emitted 0.1 second afterwards should not be more surprising
> than say 4.2 seconds afterwards.

Indeed, an event handler will be more than happy to receive the event 
regardless of when it is fired but, to be clear, the side effect I'm 
referring to is rather on the implementation side: from what I gathered 
in similar discussions in other groups, implementers do not want the 
action of registering an event handler to have the side effect of 
possibly creating an event, in other words to have any impact on the 
stream of events that will be generated. This is where Dom would start 
arguing about trees that fall in a forest [1].

I do not know whether there is a particular good technical reason why 
this should not or cannot be done. I do not know either if "replaying 
the last event" could be seen as different from "creating a new event".


[1] http://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest
Received on Thursday, 11 June 2015 11:50:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:25:14 UTC