See also: IRC log
DSR:Dave Raggett, Representing Volantis
RESOLUTION: Last week's minutes are approved
RB: WAI wants to talk about discovery of events...
RB: Joint meeting, some list discussion
JS: Didn't understand status on error event
AvK: They dropped it
JS: Pity they dropped the exception. CDF might not be the best place to do it, but I think a security exception is needed
DS: Good idea to have a call with SVG
AvK: THink there has been progress already
<darobin> ACTION: RB to sort out a joint call with SVG after D3EV is out [recorded in http://www.w3.org/2006/04/03-webapi-minutes.html#action05]
<trackbot> Created ACTION-122 - Sort out a joint call with SVG after D3EV is out [on Robin Berjon - due 2006-04-10].
RB: Lot of discussion about focus etc.
<anne> only BjÃ¶rn is the editor
... only argument that makes sense is that non-bubbling events is a pain to have to deal with.
AvK: Only the way they are
... if you adda listener for both target and XXX would work fine for Xforms
DS: They didn't seem to think so.
AvK: They didn't respond. They said registration is an issue.
RB: They also had the argument taht they have had their spec for quite a while.
JS: Xforms can add an event without us, if they want to. Don't see why they can't add a bubbling focus
RB: we would need to allow them to do it in a null namespace
DS: SVG also want to keep DOMfocus
RB: Is it ia hasssle to kee them in?
JS: No, not really
AvK: If we keep them, both events are generated and specs will specify handling for both?
RB: Would expect so, except one will bubble, one won't
AvK: So we have to define ordering
RB: That sounds relatively simpler
<bjoern> We did that before we dropped DOMFocus, iirc
Avk: We do blur/focus. then DOMfocus* in opera
JS: We have both, just for Xforms. Don't know ordering. Doubt it would be an issue to change
DS: Are we going to change what DOM2 syas?
<schepers> "Although all EventListeners on the EventTarget are guaranteed to be triggered by any event which is received by that EventTarget, no specification is made as to the order in which they will receive the event with regards to the other EventListeners on the EventTarget."
Avk: already changed
<anne> for event listener ordering
JS: that's not relevant ot this question
RB: can we keep them then?
[works for me]
RESOLUTION: We don't drop DOMfocus* after all. We end up with both pairs and need to define ordering
JS: Can we deprecate the DOM* ?
<darobin> RATIONALE: other groups like them, the bubbling is useful, and it's not a lot of work
RB: Different discussion... if we do, would we have other events that match bubbling?
AvK: Should see if we can change eventListenerNS to do more than target/capture phase
RB: Need to have a proposal on the table to discuss this usefully
Avk: Specific issue is to have more listener phases than target and bubble together and just capture
<darobin> ACTION: JS to draft a proposal for adding more options to addEvtListNS so that people could have more control over e.g. the bubbliness of their events
<trackbot> Created ACTION-124 - Draft a proposal for adding more options to addEvtListNS so that people could have more control over e.g. the bubbliness of their events [on Jonas Sicking - due 2006-04-10].
JS: We are keepiong doubled events. We could deprecate them but still keep them in.
DS: Or deprecate focus/blur. If implementations do both, why deprecate teh better specified one
JS: Becaus focus/blur is used an order of magnitude more
RB: Let's wait until we have a proposal
[/me thinks that we could happily deprecate either if we chose... but...]
JS: Deprecating something doesn't make it go away very fast
AvK: Deprecating means that user agents still have to support it forever. affects conformance of new content
DS: Is it the actual strings DOMfocus* that Xforms uses?
RB: Think maybe we can reach some for of agreement?
AvK: Agree with Ian's proposal of last week
DS: Would like to put it off one week - haven't had time to cover it but don't like the proposal
RB: OK, delay it one week
<darobin> RB: I think people like the milliseconds since Unix epoch proposal
GE: I like that
AvK: IE doesn't have it, so we can choose what we will do
<bjoern> I'd prefer uas pick some point in time and give ms relative to that. doesn't have to be unix epoch, could be load time etc.
RB: Should be interoperable
JS: Would be a 64-bit?
<bjoern> long long
RB: Would have to be 64-bit if we want it to be working...
<bjoern> Number in ES
RB: 'cause it is
... Maciej seems to imply that we need 64-bit.
<mjs> imply what?
JS: That would keep us safe for a while (few 100 million years)
RESOLUTION: We will use milliseconds since unix epoch
<anne> mjs, the issue of publishing the next draft of Window came up (after the one being published this week), any ETA?
RATIONALE: That can be done in a 64-bit integer to keep it safe for 500 million years, which is enough for now
<mjs> anne: anywhere 1-3 months from now I guess, depends on what we want to have in it
AvK: Just have to decide if we want it in - seems to work pretty interoperably
JS: Only issue on windows platform is when it should fire - every tie .detail is an even number, or when it is 2?
AvK: Addressed that. See link
<mjs> can someone remind me of the number?
AvK: at the moment dblclick is dispatched when you get an even number in .detail (which covers what different platforms do)
<mjs> I can't seem to remember it or how to ask Zakim for it
DS: I think this is because of the way IE accepts windows itself.
<mjs> Zakim I am ??P2
AvK: Increment of .detail is platform specific. Just a way to determine when you dispatch dblclick
<Zakim> chaals, you wanted to ask how we expect these to work / be used on mobiles
RB: If you don't have a pointer device you don't get a dblclick
AvK: You don't get mouseover either
<schepers> maybe they could map it to activate for mobiles?
JS: Would be useful to add comment to that effect on teh event
AvK: so browsers generate those
events somehow on mousemove to make things work
... blah blah blah
DS: Is dblclick typically an activation event?
<anne> AK: neh
<anne> It's all fine by me and I'm not saying we should be recommending its usage (or letting authors check for UIEvent.detail === 2 which is essentially the same thing), but it's used and has to be supported by UAs
CMN: Think that we need to accept that it is there, and will be used in high-performance applications with limited applicability, but should either figure out how to recommend somthing about generalising its use ala activate/click., or recommend against it for now on teh web at large
<schepers> could this just be a "shorthand" for UIEvent.detail === 2?
<mjs> double click doesn't really need to be supported by the platform, the UA can synthesize it itself
[sure, but that doesn't solve the problem unless you are geerating .detail on mobiles, keyboard, etc]
<anne> UIEvent.detail modulo 2 === 0 (because UIEvent.detail can get higher than 2)
JS: Any reason why a mobile couldn't dispatch dblclick?
<sicking> bjoern, yes
CMN: The problem is that you need
to think about real usage scenarios,
... but no need to imagine a total impossibility. Just don't break real things
<anne> this is mostly about mouse clicks or perhaps activation requests at most...
GE: Mobiles have a longclick, but don't know if that maps to dblclick
RB: I have a proposal for longclick, and will send it this week.
AvK: It's a press or click?
GE: Something different?
AvK: So for scrolling you listen for a scroll event.
RB: There are people who want to do this?
JS: Yeah... sort of.... we have
all events living in DOM 3 Ev
... so guess that we should raise issue on a couple of them that need to be tightened up.
RB: Yes, please raise issue for that.
AvK: Events in D3Ev are just guidelines for other specifications
JS: So what purpose do they fulfil?
<bjoern> We give the names, the interfaces, rough semantics
AvK: So we don't get 8 different focus events - we only have 2, and they can be used in different specs - each spec defining how they are fired etc within that format
<bjoern> doesn't make sense for HTML/SVG/XForms to define the interfaces again and again...
MJS: We need to be clear which events are making requirements on implementations, which are making them on other specs
DS: If we decide that, but not clear yet that we do
AvK: Not sure if anything else is possible
RB: Some events are defined in teh DOM, soome need to be defined elsewhere, such as a click wich needs to know what the clickable area for something actually is.
MJS: Click can be defined in terms of other mouse events
[CMN but that doesn't solve the problem RB identified]
MJS: Right, but you define click in terms of other mouse things then defer to language to define semantics of those
DS: There is an example of this in SMIL
DS: out of bounds events
<schepers> Raised when one of the following happens:
<schepers> * by any input from the mouse or other input device that brings the mouse cursor from outside to within the bounds of a media element's rendering space, regardless of what part, if any, of that rendering space is visible at the time, i.e., z-order is not a factor.
<schepers> * by any other action that moves the "cursor" or "pointer", as defined by the implementation, from outside to within the bounds of a media element's rendering space, regardless of what part, if any, of that rendering space is visible at the time, i.e., z-order is not a factor. An implementation may decide, for instance, to raise an inBoundsEvent on an element whenever it gets the focus, including when keystrokes give it the focus.
<schepers> A media element's bounds are restrained by the bounds of the region in which it is contained., i.e., a media element's bounds do not extend beyond its region's bounds. The inBoundsEvent is delivered to media elements only, and does not bubble.
RB: Anyone want an action to draft specification conformance language?
<schepers> Note that, unlike with keyboard focus which can only be active on one object at a time, the state of being within an object's bounds can be true for multiple objects simultaneously. For instance, if one object is on top of another and the cursor is placed on top of both objects, both would have raised an inBoundsEvent more recently than the raising of any respective outOfBoundsEvent.
<darobin> bjoern, are you working on a specification conformance section?
AvK: Think BjÃ¶rn is working on it
<darobin> so you don't need an action?
MJS: Should events besides mutation have their behaviour defined in spec?
RB: SHould have high-level semantics described
<bjoern> ACTION: BH to draft text for a specification conformance section in DOM Level 3 Events.
<trackbot> Created ACTION-125 - Draft text for a specification conformance section in DOM Level 3 Events. [on Bjoern Hoehrmann - due 2006-04-10].
AvK: Custom events need to be described
MJS: Custom event never needs to be dispatched by implementation, s onot relevant - interface already defined
AvK: UI Event not required to be
... custom events, for example, are.
MJS: Issue is whether D3Ev defines when they are dispatched or should it just define name, interface?
AvK: ...Broad semantics and properties
MJS: Click is mousedown, moseup
JS: No, because it can also be dispatched without mouse interaction
AvK: If you dispatch click, mousedown doesn't need to be before.
<bjoern> (When a click occurs depends on the platform, e.g. if there is a long time between down/up, you might not get a click)
MJS: If you have a mousedown, mouseup you dispatch click (you may dispatch it in other places). If we want to define that, it should be in D3Ev
RB: If you hold down a mouse too long it turns into a contextual click and you get no click event. Seems hard to define this in D3Ev
MJS: If we don't define it at all, we can't make assertions so it is hard to make tests, therefore pointless
hang on anne
AvK: Helps us to allow others to know what requirements they need to make
JS: We can't make tests for it
AvK: But we can check that they make tests that make sense
<mjs> (Something I said earlier on phone): platform differences affect language specs like HTML or SVG just as much as DOM Events - if it should be the same in all XML languages then it should be defined in DOM Events
<bjoern> This sounds a lot like we should discuss this per mail first
AvK: If it is a conformance thing
on a spec you don't need a test suite. So we define broad
semantics. Defining them really specifically means really
complex details (e.g. what elements it applies to, for submit,
... so makes sense to define broad semantics, and leave details to specifications. Needs to be stated in spec conformance section what they need to define.
<scribe> ACTION: Anne send somethin like this to the list
<trackbot> Created ACTION-126 - Send somethin like this to the list [on Anne van Kesteren - due 2006-04-10].
JS: Think that I want to avoid that different specs define click in different ways so it is hard to do CDF, or specs look at our version and make a slightly semantically different one. Those have both happened and should be avoided
DS, RB, AvK: agreed
[/me suggests a note to that effect would be a useful addition]
RB: So we should defer HTML events discussion - if we define this D3EV we don't need HTML events
AvK: Well, we have HTML events spec to define these specifically for HTML
RB: This is the point at which we don't have consensus
RB: Any comments on ReTest?
RB: Test plan for window?
MJS: Started writing some, spec
is informal so hard to get them all done yet but will have
... every testable assertion has a test.
RB: Do you need more, or going
... you won't get help without a specific request...
MJS: OK, will look for specific bits...
<iand> I've written some informative XHR tests, but only a few.
AvK: Don't have a resolution for dblclick.
DS: Chaals had raised some objections that need to be addressed
<anne> The issues already exist. UIEvent.detail!!!
<bjoern> ('load' is a good example here, when does it occur, which event targets is it dispatched to? SVG modifies this with externalResourcesRequired="", HTML has fallback content, I don't think you can clearly define the details without discussing HTML and SVG specifically. Device event types like mouseup probably don't have to be discussed for those formats specifically)
<anne> (same for mousemove, etc.)
CMN: There are issues that we need to note in teh spec about usage, but so long as they are noted and will be adrressed I am happy to have dblclick go into things taht are specified
<mjs> bjoern, I agree (probably) for 'load', but not for, e.g., 'keydown'
CMN: (we have similar issuess over mousemove, etc already)
<anne> (it's just an event for UIEvent.detail modulo 2 === 0, it's not something horrific)
<mjs> bjoern, depends on if we expect the event to have language-specific dispatch semantics
<anne> (it's also something Opera supports...)
<mjs> (oops, sorry about inappropriate use of colon)
proposed resolution: we accept dblclick and note an issue on how it works in teh real world
<iand> will start adding tests for normative parts of XHR this week
AvK: Have done some testing
... generating static files
RB: Not using ReTest?
<iand> i checked in a retest framework
<iand> you can incorpate tests into that
RB: Would be good if the two of you were doing the same thing.
AvK: Fine by me if someone else does the testing.
<iand> better for people other than editor to write tests I think
AvK: have been doing small tests
<iand> anne, can you share the tests you've written?
RB: We have one Java guy, Christophe, people have ased that Cameron McCormack be invited expert to help out
DS: In favor
<darobin> ACTION: RB to figure out with Dean about inviting Cam
[CMN in favour too]
<trackbot> Created ACTION-127 - Figure out with Dean about inviting Cam [on Robin Berjon - due 2006-04-10].
<mjs> it will save me the work of having to merge his ReTest Java support into cvs
AvK: Made some resolution at face
... problem is that IE behaviour is inconsistent. Sometimes it does that, sometimes when readystate is 2 and you call abort it just resets the object without calling onreadystatechage
JS: So sometimes abort doesn't take it to 4 first, sometimes it does?
AvK: There is a bug report that describes what happens
RB: Then we can emulate that behaviour - so people are not relying on getting a 4 after they have had 2
AvK: They are not relying on that. Couldd rely on it going to 4 after 1 but seems unlikely
RB: Think they rely on it after 3
AvK: We don't go to 4 in Opera
JS: You only get to 4 if you haven't gone past 1?
JS: THink we should just reset always
RB: Fine, if it doesn't break existing content
AvK: IE is inconsistent
RB: If it is lie you say it is stupid and can't be relied on
JS: Arguing to go straight to reset without any calls. Seems unlikely people will expect to go to 4
RB: Right, that might crash
DS: Think it is safe not to rely
on Mozilla behaviour, because that can be changed
... would rather it be correctly. If there is nothing people can rely on from IE, I am not convinced that tey will implement it correctly.
AvK: Believe they will join the group, so would eithher expect to get it right, or object.
MJS: This is one of the few things they are changing in IE7 so there is at least some reason to believe they will change, and current behaviour seems unlikely to be relied on
RESOLUTION: We want to go straight to resest
RATIONALE; there is nothing else people rely on anyway
<darobin> RRSAgent: make minutes
<scribe> ACTION: Anne to update XHR spec to go straight to reset on abort, not readystate 4 [recorded in http://www.w3.org/2006/04/03-webapi-minutes.html#action11]
<trackbot> Created ACTION-128 - Update XHR spec to go straight to reset on abort, not readystate 4 [on Anne van Kesteren - due 2006-04-10].
<darobin> RRSAgent: make minutes