Re: DOM3 Events call today/tonight?
On Wed, 25 Feb 2009, Olli Pettay wrote: 'load' is a special event in many ways. 'load' events dispatched somewhere in document (for example for img) don't propagate to 'window'. (for capture -- they don't bubble) And the 'load' event which is dispatched to 'window', has 'document' as its target. This all is required for backwards compatibility. The HTML5 spec now requires all of the above. This is related to http://www.w3.org/2008/webapps/track/issues/44 As far as I can tell, all the requirements are now in HTML5, so DOM Events can avoid talking about Window if it wants to avoid dependencies on HTML5. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Minutes Re: DOM3 Events call today/tonight
On Feb 25, 2009, at 21:14 , Charles McCathieNevile wrote: Mutation events are proposed for next week Are these still as contentious as they used to be? If so, splitting them out into their own spec might make sense. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: DOM3 Events call today/tonight?
On Wed, Feb 25, 2009 at 8:27 AM, Charles McCathieNevile cha...@opera.com wrote: Hi folks, unfortunately I have not been able to catch up with Doug (a combination of both of us travelling and then I had a minor accident that put me out of commission for a while), so as far as I know we have no agenda planned for tonight's call. The call is booked: Telephone: +1.617.761.6200 meeting code 3663 (DOM3). Pacific time: 11.30am - 1pm Boston time: 2.30pm - 4pm UTC: 1930Z - 2100Z CET: 2030 - 2200 If anyone would like to hold a call, please reply to this thread - if there are no replies in the next 90 minutes (by 1900CET, 10am Pacific, 1pm Boston), we will postpone the restart until next week, and Doug and I will coordinate to ensure there is an agenda. 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). sorry about this Garrett
Re: DOM3 Events call today/tonight?
On 2/25/09 7:46 PM, Garrett Smith wrote: On Wed, Feb 25, 2009 at 8:27 AM, Charles McCathieNevile cha...@opera.com wrote: Hi folks, unfortunately I have not been able to catch up with Doug (a combination of both of us travelling and then I had a minor accident that put me out of commission for a while), so as far as I know we have no agenda planned for tonight's call. The call is booked: Telephone: +1.617.761.6200 meeting code 3663 (DOM3). Pacific time: 11.30am - 1pm Boston time: 2.30pm - 4pm UTC: 1930Z - 2100Z CET: 2030 - 2200 If anyone would like to hold a call, please reply to this thread - if there are no replies in the next 90 minutes (by 1900CET, 10am Pacific, 1pm Boston), we will postpone the restart until next week, and Doug and I will coordinate to ensure there is an agenda. 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). HTML 5 says that If the Document is in a browsing context, then queue a task to fire a load event at the Document's Window object. And that is what at least Gecko does. 'load' is a special event in many ways. 'load' events dispatched somewhere in document (for example for img) don't propagate to 'window'. And the 'load' event which is dispatched to 'window', has 'document' as its target. This all is required for backwards compatibility. This is related to http://www.w3.org/2008/webapps/track/issues/44 -Olli sorry about this Garrett
Re: DOM3 Events call today/tonight?
On Wed, Feb 25, 2009 at 10:16 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 2/25/09 7:46 PM, Garrett Smith wrote:
On Wed, Feb 25, 2009 at 8:27 AM, Charles McCathieNevile
cha...@opera.com wrote:
Hi folks,
unfortunately I have not been able to catch up with Doug (a combination
of
both of us travelling and then I had a minor accident that put me out of
commission for a while), so as far as I know we have no agenda planned
for
tonight's call.
The call is booked:
Telephone: +1.617.761.6200 meeting code 3663 (DOM3).
Pacific time: 11.30am - 1pm
Boston time: 2.30pm - 4pm
UTC: 1930Z - 2100Z
CET: 2030 - 2200
If anyone would like to hold a call, please reply to this thread - if
there
are no replies in the next 90 minutes (by 1900CET, 10am Pacific, 1pm
Boston), we will postpone the restart until next week, and Doug and I
will
coordinate to ensure there is an agenda.
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).
HTML 5 says that If the Document is in a browsing context, then queue a
task to fire a load event at the Document's Window object.
And that is what at least Gecko does.
'load' is a special event in many ways. 'load' events dispatched somewhere
in document (for example for img) don't propagate to 'window'. And the
'load' event which is dispatched to 'window', has 'document' as its target.
This all is required for backwards compatibility.
I see.
window does implement EventTarget
. It has addEventListener, removeEventListener, and dispatchEvent. The
callback gets the |event| parameter.
In Webkit/Gecko, the |event.target| is document.
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html lang=en
head
titleload/title
script type=text/javascript
window.addEventListener('load', function(ev) {
var m = document.getElementById('m');
m.firstChild.data = this: + this +
\nev.target: + ev.target +
\nev.currentTarget: + ev.currentTarget;
}, false);
/script
/head
body
pre id=mLoading.../pre
/body
/html
Results:
Opera
this: [object Window]
ev.target: [object Window]
ev.currentTarget: [object Window]
Firefox:
this: [object Window]
ev.target: [object HTMLDocument]
ev.currentTarget: [object Window]
Webkit:
this: [object DOMWindow]
ev.target: [object HTMLDocument]
ev.currentTarget: null
This is related to http://www.w3.org/2008/webapps/track/issues/44
I see Jonas' comment along the lines of when we tried to implement it
this way, it broke sites; Arguably, sites that expected event.target
to be document were already broken. Those sites were expecting
nonstandard behavior which does not work in Opera.
The other consideration is that adding a load event to document. Just
use the example above and change window.addEventListener to
document.addEventListener. The result is:
Webkit, Gecko: Loading...
Opera:
this: [object HTMLDocument]
ev.target: [object HTMLDocument]
Opera also (oddly) supports load event on document.body as an
intrinsic event. The target is also window.
!DOCTYPE HTML
html lang=en
head
titlebody onload/title
/head
body
pre id=mLoading.../pre
script type=text/javascript
document.body.onload = function(ev) {
var m = document.getElementById('m');
m.firstChild.data = this: + this +
\nev.target: + ev.target;
};
/script
/body
/html
Opera:
this: [object Window]
ev.target: [object Window]
Opera also supports intrinsic load event on document. Change the
example above to |document.onload = function(ev) |.
Result in Opera:
this: [object HTMLDocument]
ev.target: [object HTMLDocument]
Interesting stuff. I wonder why Opera implemented that.
As an author, I would favor window.addEventListener. In the callback
would not expect anything of ev.target, but could expect |this ===
window|.
Garrett
[1]http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Registration-interfaces
Re: DOM3 Events call today/tonight?
Charles McCathieNevile wrote: On Wed, 25 Feb 2009 22:59:06 +0100, Sean Hogan shogu...@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.
