See also: IRC log
<trackbot> Date: 11 March 2009
<trackbot> ISSUE-44 -- Should DOM3 Events cover the interaction of events and the Window object? -- RAISED
<smaug> hmm, "passcode not valid"
yeah, me too
agenda says "3661#"
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
AB: agenda is
... do other people typically join this call?
DS: Travis from Microsoft used to
... but we don't have to wait for him to start the meeting
AB: Charles created this agenda;
mostly Actions, Issues and Pub plans
... any change requests?
[ None ]
AB: any objections to confirming
last week's minutes?
[ No Objections ]
AB: All of the D3E Issues and
Actions are available at:
... I noticed 5-6 of the issues are in the RAISED state
... Briefly, what process is used to move an Issue from Raised to Open?
... Just curious (we don't use RAISED state in Widgets)
DS: raised means the issue is
... it is changed to Open when the group agrees to take it on
... then we issue Actions against the Open Issue
<scribe> ... Pending Review means the issue is still open and pending the actions related to it are closed
DS: that was recorded a long time
ago to test Tracker
... I should close just close it
... I will change the Due Date to the 18th
... I haven't uploaded my changes yet
AB: I noticed the latest ED was quite old
DS: yes; I'm still getting back
... I will check in a new version before the next call (Mar 18)
DS: I have some wording in my
... I'll complete this action when I make my upload next week
... I will define a default action for the load event
OP: default action?
DS: no, sorry, I meant default
... and let the individual specs override how the load event works
... i.e. how it is dispatched
... and what its target is
OP: yes, I think you are correct about the target
DS: we may have to talk more
about the Window
... I'll have to redo the chart to include Window
OP: Window is the parent node above the document
DS: so bubble goes up to window?
... check the mail around ISSUE #44
... it is dispatched to Window but its target is Document
DS: need to be careful about HTML
... don't want SVG and HTML doing diff things
<smaug> all the other events except load propagates from document to window
<shepazu> ACTION: shepazu to coordinate with SVG WG about 'window', to add behavior like HTML's [recorded in http://www.w3.org/2009/03/11-webapps-minutes.html#action01]
<trackbot> Created ACTION-323 - Coordinate with SVG WG about 'window', to add behavior like HTML's [on Doug Schepers - due 2009-03-18].
DS: if we put this in D3E it would get folded into SVG
OP: we can talk about default view and not Window
<shepazu> where window == defaultView
DS: this is related to our previous discussion
AB: so what do we do with this then?
DS: leave it open
OP: I sent some emails to the list today
OP: no one supports
... Whenever mutation listeners are used, the relevant DOM operations slowdown a lot in all browser engines
... I've been talking to the ARIA people
<smaug> "chaals> roughly, we don't see that changing them is a great idea. We implemented them ages ago, and while they imply a performance hit, they do something that seems useful"
AB: how do we reflect Chaals' comments?
DS: one way is mutation events as
defined in DOM2
... i.e. keep them as they exist
... could find intersection of the browser and throw away others
... could define new model
... would like to have a more performant model
... and define a mapping from the new model to the existing definition
... and deprecate those that aren't implemented by all of the browsers
OP: Jonas made a proposal last summer
AB: do you have a pointer to that proposal?
AB: so only 3 of the 7 mutation events are implemented by these three browsers?
OP: yes, that's the case
... the slow down is amazing; used a deep tree
DS: the slowdown is actually a
big usability issue particularly in accessibility use
... because there may not be an indication it is occuring
... may need a dedicated ARIA event
OP: yes; and some web apps may decide not use these events if for example it was doing some location stuff
<smaug> OP: yes; and some web apps may decide not use these events because it would slow down performance also for people who don't use a11y stuff
OP: the email from Boris indicates the .style change also cause slowdowns
AB: I think Olli completed this action right?
OP: yes I've already closed
... should we skip this today?
AB: Issue is: What should D3E say
about the window object and where events are fired...
DS: we've already talked about this
AB: this in the RAISED state; is that OK?
AB: anything else on Issue #44?
[ No ]
AB: issue is: Consider changing
ordering/firing of mutation events?
... any discussion on this issue?
DS: there are no related
... Olli, what are your thoughts?
OP: I'd like to get comments from
... I think Jonas wants to change it
... anyone else?
DS: I think Maciej
OP: it's bad for implementations but OK for content authors
DS: but if perf is bad then that's bad for the authors too
OP: not clear when the events should be fired
AB: since Opera hasn't addressed Action #320, seems like we should defer discussion until next week
OP: back to mutation events;
chaper 1.7.7 ...
... the grey/gray block text
... why was that added?
DS: this was added for
... in SVG, create element is used to make trees in the DOM but not in the document
... mutation events aren't fired for things that are not in the document
OP: I don't understand why
<shepazu> I propose that we state explicitly in the spec that if there is no event listener registered, and if the event does not have a default handler, then the implementation may choose not to fire an event for that action (which is what browsers do)
AB: any comments on Doug's proposal?
OP: browsers do that for
... other events don't slow things down as much
AB: the question is: Are we still expecting to have a new Editor's draft on 2009-03-18?
DS: yes, that is still the
... don't expect it to be ready to publish by then
... This is Action #321 http://www.w3.org/2008/webapps/track/actions/321
AB: keep it open?
AB: so that would be another WD, right?
AB: any discussion on the LCWD?
DS: no we haven't discussed that yet; one step at a time
OP: events are hard; must get it right and they are core to so many other specs
AB: DOM3E Issues and Actions
... what is Carmelo's role?
DS: helping with the test development
AB: meeting adjourned
Title: DOM 3 Events Voice Conference
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/A11Y people/ARIA people/ Succeeded: s/Topic: Publication schedule// Found Scribe: Art Found ScribeNick: ArtB Default Present: Shepazu, Art_Barstow, smaug Present: Art Doug Olli Regrets: Charles Agenda: http://lists.w3.org/Archives/Public/www-dom/2009JanMar/0004.html Found Date: 11 Mar 2009 Guessing minutes URL: http://www.w3.org/2009/03/11-webapps-minutes.html People with action items: shepazu[End of scribe.perl diagnostic output]