W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: DOM3 Events call today/tonight?

From: Sean Hogan <shogun70@westnet.com.au>
Date: Thu, 26 Feb 2009 14:49:47 +1100
Message-ID: <49A6115B.3020706@westnet.com.au>
To: Charles McCathieNevile <chaals@opera.com>
CC: Garrett Smith <dhtmlkitchen@gmail.com>, WebApps WG <public-webapps@w3.org>
Charles McCathieNevile wrote:
> On Wed, 25 Feb 2009 22:59:06 +0100, Sean Hogan 
> <shogun70@westnet.com.au> wrote:
>
>> Garrett Smith wrote:
>>> It might be worth discussing the load event;
>>> http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-load
>>>
>>> Seems that it is "specified" to fire on Document or Element (instead
>>> of window).
>>>
>> I would also suggest a progress event on document or window.
>> Ideally it would be triggered every 100ms during page-load.
>
> I would suggest that the editor of the progress spec get back to 
> dealing with the last issues raised by Ian, but he is writing this 
> email :)
Sorry, I don't understand. Is the progress spec anticipated to augment 
DOM-3-Events for HTMLDocument and Window?

>
> However the issue of timing is an interesting one. I am not sure how 
> handy it is to expect a particular frequency, since it will vary 
> pretty wildly depending on networks as well as other stuff. As a data 
> point, I am told that while Australian broadband connections manage to 
> deliver on average almost 2/3 of their advertised speed, which is a 
> relatively good correspondence although advertised speeds for things 
> people pay for are often are often pretty low, in terms of connections 
> to actual offshore services they are getting something like 1/8. So 
> you would get small progress over a long time.
>
The basis for the 100ms event interval is related to the rendering of 
new content on the web-page. If new content has arrived then scripts 
should be able to munge it before it is rendered, or at least soon 
afterwards. It doesn't matter how much content has arrived.
> When you emit an event it is pretty low cost. But when you deal with a 
> javascript that listens for that event and then does something else, 
> it is more expensive - and when that starts to eat the battery of your 
> mobile phone, maybe 10 times a second is more than people want.
>
> Anyway, I leave the issue of whether to request user agents to make a 
> particular timing available to the specs that use progress events, 
> although I have reservations about the wisdom of conditioning authors 
> to expect things just because broadband in a few countries can deliver 
> them easily.
>
I should raise this as a request for HTML5.
Received on Thursday, 26 February 2009 03:52:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT