- From: Doug Schepers <schepers@w3.org>
- Date: Fri, 29 Oct 2010 11:30:45 -0400
- To: "www-dom@w3.org" <www-dom@w3.org>
Here are the minutes for the DOM3 Events Telcon of 27 October 2010: Meeting: DOM3 Events Teleconference Date: 27 October 2010 Agenda: discussing LC comments http://www.w3.org/2008/webapps/track/products/2 Attendees: Olli Pettay, Jacob Rossi, Doug Schepers scribeNick: jrossi chair: shepazu Topic: ISSUE-134 -- Consider making useCapture parameter of add/removeEventListener optional -- raised http://www.w3.org/2008/webapps/track/issues/134 smaug_: not sure if webidl allows this smaug_: if webidl already defines that it's ok to not use all the parameters, and if it defines what the default value is those cases then we dont need to care about this case at all smaug_: i dont like making it optional, but if webidl does that then i dont argue against that shepazu: right now we're not using webidl smaug_: but if browsers implement it using webidl, and more than just idl syntax smaug_: if webidl allows calling native methods with fewer params than specified, then it probably defines the default values jrossi: provided webidl allows optional parameters and that we can specify useCapture's default to be false, we don't have a problem with it either way smaug_: a little worried that people will understand only part of dom3 events if it is left optional shepazu: most people may never need it and so understanding is not necessary jrossi: isn't this not backwards compatibile for other browsers? smaug_: yes shepazu: older browsers won't have new events and such either shepazu: IE before 9 didn't allow it, so there's no question there (IE6-8). Firefox/Safari/Opera/Chrome are all really aggressive about pushing updates. shepazu: better to have the default that's the proper default rather than screw up people who use true/false without understanding it shepazu: first let's look into what webidl says about this and if this is an option, if this is an available option there then we'll go ahead and make this change RESOLUTION: accepted. will look at webidl for this Topic: ISSUE-146 -- Capture-phase listeners invoked on targets -- raised http://www.w3.org/2008/webapps/track/issues/146 smaug_: useCapture of type boolean smaug_: If true, useCapture indicates that the user wishes to add the event listener for the capture phase and target only, i.e. this event listener will not be triggered during the bubbling phase. If false, the event listener must only be triggered during the target and bubbling phases. smaug_: once gecko implemented this, people were relying on it RESOLUTION: Point out wording in spec to commentor. shepazu: "Event listeners registered for this phase must handle the event once it has reached its target." jrossi: perhaps in section 3.1 you could clarify by saying event listeners registered for either capture or bubble jrossi: since you can't explicitly register for target phase RESOLUTION: fix section 3.1 for issue 146 Topic: ISSUE-153 -- Converting wheel events to mousewheel and DOMMouseScroll -- raised http://www.w3.org/2008/webapps/track/issues/153 smaug_: consider making this part non-normative shepazu: absolutely right. also correct the errors! RESOLUTION: make non-normative and correct the errors Topic: ISSUE-171 -- Consider removing Event.timeStamp value 0 -- raised http://www.w3.org/2008/webapps/track/issues/171 RESOLUTION: accept the comments pending further discussion Topic: ISSUE-172 -- Fix Event.timeStamp -- raised http://www.w3.org/2008/webapps/track/issues/172 smaug_: in script libraries, you probably call the init method right after createEvent smaug_: the time will probably be the same smaug_: if you even care about timestamp jrossi: agrees jrossi: don't know how you can "guess when the event will really occur" as Boris says jrossi: doesn't have precognitive abilities shepazu: he also says milliseconds since epoch might not be accurate jrossi: almost all timestamps (for other environments, such as server side) are allowed to be sec since epoch jrossi: so it might be useful for event timestamps to align with those systems shepazu: might be useful for animation to have these be more accurate smaug_: yes, but that might be something different jrossi: agrees shepazu: im happy to change it if there's a more concrete proposal shepazu: but not sure exactly what we'd do here RESOLUTION: going to keep it as epoch pending further discussion Topic: ISSUE-147 -- re-dispatching an event that already has its flow started -- raised http://www.w3.org/2008/webapps/track/issues/147 smaug_: shouldn't be possible smaug_: it would cause problems, for example, related to istrusted property RESOLUTION: clarify that it is not possible
Received on Friday, 29 October 2010 15:30:47 UTC