Minutes: DOM3 Events Telcon, 27 October 2010

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
Attendees: Olli Pettay, Jacob Rossi, Doug Schepers
scribeNick: jrossi
chair: shepazu

Topic: ISSUE-134 -- Consider making useCapture parameter of 
add/removeEventListener optional -- raised
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
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
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
RESOLUTION: accept the comments pending further discussion

Topic: ISSUE-172 -- Fix Event.timeStamp -- raised
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 
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
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