WebAPI
3 Apr 2006

Dave introduces himself

DSR:Dave Raggett, Representing Volantis

Last week's minutes

RESOLUTION: Last week's minutes are approved

telcon times

Joint calls - WAI

RB: WAI wants to talk about discovery of events...

CDF comments

RB: Joint meeting, some list discussion

JS: Didn't understand status on error event

AvK: They dropped it

<anne> http://www.w3.org/2004/CDF/specs/CDR/wp-1/cdf.html

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

joint calls - 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].

D3Events

RB: Lot of discussion about focus etc.

<anne> only Björn is the editor

JS: right...
... only argument that makes sense is that non-bubbling events is a pain to have to deal with.

AvK: Only the way they are designed
... 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

<anne> see http://annevankesteren.nl/test/dom/events/005.html

DS: Are we going to change what DOM2 syas?

<schepers> http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-basic-h3

<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> see http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Event-groups-h4 ...

<anne> for event listener ordering

JS: that's not relevant ot this question

DS: OK

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?

JS: No

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?

ISSUE-56

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

ISSUE-52, DOM3EV: DOMTimeStamp - Number or Date in ES?

<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 milliseconds.
... Maciej seems to imply that we need 64-bit.

<mjs> imply what?

<anne> mjs!

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?

dblclick

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?

<anne> http://lists.w3.org/Archives/Public/public-webapi/2006Mar/0386

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

<darobin> err

<darobin> right

DS: I think this is because of the way IE accepts windows itself.

<mjs> Zakim I am ??P2

<sicking> heh

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

<anne> exactly

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)

<schepers> right

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.

HTML Events specification

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

<schepers> http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil21-profile.html#q21

DS: out of bounds events

<schepers> inBoundsEvent:

<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

<bjoern> yes

<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 implemented
... 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

Avk: is

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

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, etc)
... 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

Test writing

RB: Any comments on ReTest?

No

RB: Test plan for window?

MJS: Started writing some, spec is informal so hard to get them all done yet but will have them
... every testable assertion has a test.

RB: Do you need more, or going ok?
... 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.

RB: XHR?

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

AvK: No

<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

Java

<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

ISSUE-58 - XHR

AvK: Made some resolution at face to 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?

<anne> https://bugzilla.mozilla.org/show_bug.cgi?id=218236#c11

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?

AvK: Right

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