CMN: to pick up from yesterday

JL: will concur with any resolution on issue-15

Issue 15 -> http://www.w3.org/2005/06/tracker/webapi/issues/15

CMN: any resolution?

JS: we believe they are mutually exclusive

RESOLUTION: load and error are mutually exclusive in issue-15

Issue-16 -> http://www.w3.org/2005/06/tracker/webapi/issues/16

GE: is it common to use functions as getters?

JL: should be properties

<bjoern> (only isDefaultPrevented would remain if we adopt one of the alternate custom event proposals...)

JS: yes, should be properties

GE: we don't have real properties in Opera so this is harder. So we can't dispatch events on properties. But not a big issue

RESOLUTION: make methods in Issue-16 properties instead, so close issue

Issue-19 -> http://www.w3.org/2005/06/tracker/webapi/issues/19

<bjoern> so remove the leading is* and lower case the following letter in the names?

<JimJibber> yes bjoern, you're just getting the action now :-)

<scribe> ACTION: BH to change methods from issue-16 into properties

<trackbot> Created ACTION-75 - Change methods from issue-16 into properties [on Bjoern Hoehrmann - due 2006-03-03].

CMB: close this?

GE: DOM 3 doesn't need it

JS: put in a namespace

AV: but in the real world they are not

CMN: close issue

RESOLUTION: the dashboard events exist in the null namespace but DOM3EV doesn't need to explictly support them

(discussion of dashboard events by Apple)

RESOLUTION: close Issue-19

Issue-20 -> http://www.w3.org/2005/06/tracker/webapi/issues/20

<bjoern> Re issue-20, what Mozilla does is non-compliant,

<bjoern> calling initEvent again must have no effect

<bjoern> per the current spec

JS: believe Mozilla allows re-dispatching

<bjoern> (only if you re-init...)

JS: can see use cases for re-dispatching events, but not while they are in process of being dispatched

CMN: should this be a MUST? i.e. must allow it

JS: in label when it is for another element Mozilla impl. redispatches any label events to the target element
... need to check if we create a new event or re-dispatch

SS: maybe create a redispatch method?

<ssire> *joke*

CMN: so what to do? make it possible, impossible or let authors hope for the best?

JL: allow redispatch of completed events

JS: we do it, but we don't allow users to do it

CMN: anyone object to it being allowed?

SS: what would happen to cancelled event?

JS: don't know, good question. what would happen if you called stop propogation and redispatch?

<JibberJim> bjoern, can you dispatchEvent the same event in the middle of it being dispatched?

<bjoern> no

<JibberJim> in no implementations?

<bjoern> at least not per the current spec

<bjoern> I am not sure, I think some throw exceptions, some just ignore

<JibberJim> current level 3?

<bjoern> (exception is per the spec)

JL: so just leave spec as is

<bjoern> (per dom3, yes)

JS: use cases like label support redispatching in middle of events

CMN: level 3 spec says you cant

JS: it should be allowed

CMN: seems to be consensus

RESOLUTION: implementations must allow redispatch of a fully-dispatched event. a cancelled event is uncancelled and redispatched

JS: problem with uncancelling is that DOM implementatio might not have control over event object
... for custom events

ID: what happens when you cancel an event?

JS: do we really mean stop propogation?

<bjoern> (for custom events, we have some proposals to let the implementation implement CustomEvent rather than user code, so that would not be an issue there)

JS: in DOM level 2 nothing happens to the event itself when you call stopPropogation
... worry is that if we force impl. to allow redispatch will the impl. be able to actually do that if it is handed a cancelled object?

CMN: maybe redispatching a cancelled event leaves event cancelled

SS: can you determine if an event has been cancelled

JS: not from event object

<bjoern> using .defaultPrevented

JS: is it expected that a user can create its own object without using DOM methods and then dispatch it as an event? can't see how that is doable

<sicking> default prevented is not the same as canceled

<sicking> cancled is stopPropagation

<bjoern> no, in dom3 terms canceling is preventing the default action

CMN: if there's no way of knowing that object is cancelled then redispatching it is safe

JS: what happens if you prevent default action on event and redispatch it?

CMN: anyone want to take an action to build a test case and find out what to do?

JS: in theory these thinhgs should be reset and redispatched

<scribe> ACTION: AV to build test case for understanding behaviour of redispatching cancelled and stopped events

<trackbot> Created ACTION-76 - Build test case for understanding behaviour of redispatching cancelled and stopped events [on Anne Van Kesteren - due 2006-03-03].

RESOLUTION: close Issue-20 subject to action-76 not turning up something to contradict

CMN: should you be able to fetch someone else's event and pass it around

JS: DOM implementation has no way of knowing it. only by some internal interface

CMN: I spit out an event, you catch it...

JS: You implement event, call dispatch, someone else's listener catches it and stops propogation.
... so event knows to stop, but DOM doesn't

GE: should stop propogation be allowed to be overriden

JS: it's your own class

GE: DOM implementation needs to know it

JS: so not every object can be dispatched.

GE: should we make test case?

JS: can't imagine how this could work

<bjoern> that's what the current CustomEvent interface is for; it allows you to know whether propagation should be stopped...

<bjoern> likewise, if we adopt the alternate custom event proposals, the implementation could take care of it internally...

JS: implementation should be able to throw unrecognised event exception

GE: Opera gives a wrong argument exception with arbitrary object

JS: but CustomEvent interface can still be any object

<bjoern> EventException.NOT_SUPPORTED_ERR would be raised if you dispatch some custom object but don't implement CustomEvent...

JL: should call create event

<bjoern> (and/or haven't used createEvent to create it)

RESOLUTION: close issue-20

Issue-21 -> http://www.w3.org/2005/06/tracker/webapi/issues/21

CMN: any reason not to use them

<bjoern> we don't agree what this would mean exactly

CMN: not in capitals though

RESOLUTION: use RFC 2119 keywords not capitalised - just class them

-- break --

<gorm> scribe: gorm

JS: proposal is: instead of having a full hash, we have a single property where it can store all the things

AK: you get a dom object for your custom properties
... ?
... it's readonly, how would you store dom objects in it?

<bjoern> using the initCustomEvent method

<anne> bjoern, in Camaron's proposal, should .details be readonly?

<bjoern> it doesn't matter much I think

AK: where is the complete proposal then?

<bjoern> depending on what you mean by "complete", we might not have one...

<anne> bjoern, initCustomEvent and such, were are those defined?

<bjoern> http://lists.w3.org/Archives/Public/www-svg/2005Oct/0005.html

[looking at proposal from Cameron]

<bjoern> (plus http://lists.w3.org/Archives/Public/www-svg/2005Sep/0072 depending on how things work with sXBL/XBL2)

<anne> bjoern, ah, now it makes more sense, thanks

JS: the advantage of a read only details property is that cloning is simple, you will not get into issue that someone is setting it on the clone and on the initial objects

AK: you set it in the init
... seems ok, agree it's simple

GH: I also agree

JS: like it, except for the sXBL interface

AK: so we accpet it without the sXBL interface

CM: yea
... use a namespace for custom event

JS: should we throw when not providing an namespace
... ?

CM: yes an exception

JS: sounds fine

<bjoern> Note that the problem with retargetting is that the implementation might not know how to clone the .detail

<bjoern> so they either have to copy the reference, use null, or there needs to be a handler so the dom app can take care of cloning it; or the .originalEvent property as in sXBL...

<sicking> i'd say we should copy the reference

<bjoern> that would probably work, yes

RESOLUTION: We accept Camerons proposal regarding custom events except the sXBL stuff

<anne> bjoern, would it be possible for you to publish an editor's draft so we can look at what we have now?

<bjoern> by that you mean a .html version?

RESOLUTION: When cloning the .detail just copy the reference

<sicking> bjoern, can you take an action to go through the spec and remove language that says that you can create your own objects and dispatch

<anne> bjoern, yes (well, .xht works too...)

<sicking> sorry

<bjoern> I can do that for the afternoon session

<chaals> that would be great - thanks

<scribe> ACTION: bjoern to go through the spec and remove language that says that you can create your own objects and dispatch

<trackbot> Created ACTION-77 - Go through the spec and remove language that says that you can create your own objects and dispatch [on Bjoern Hoehrmann - due 2006-03-03].

Topic ISSUE-22

[opera throws a NO_MODIFICATION_ALLOWED dom exception]

[mozilla throws a custom exception telling that the property only got a getter]

JL: don't think we should define the behaviour

CM: the only possible use-case
... is to check if it's readonly

<JibberJim> IE throws a variety of different errors.

JS: IE is not going to change, i would be nervous by chaning moz
... not good to leave fairly big things undefined

GH: would be nice to define

<JibberJim> IE sometimes throws object doesn't support this action, sometimes throws Member not found, sometimes illegal assignment

GE: whats the options

CM: must throw, should, undefined

JS: would rather say MAY

RESOLUTION: The meaning of read-only should be defined in a glossary and MAY throw an exception if the user write to such an property

ISSUE-23

JS: only applies to ecmascript

JL: should do Number(<string>)

RB: how should it deal with null values

JS: DOM is lacking

<bjoern> it should probably use the internal ToString ToNumber ToBoolean functions as defined in ECMA-262, not the user level ones...

JS: null is an object
... if you do appendChild(null) we throw an exception in Mozilla
... although the spec doesn't mention
... part of the issue
... what happens if you pass appendChild(3)

[opera and moz throw exception]

RB: which arguments can be null is a seperate issue
... other issue is, what todo with objects of the wrong time

JL: you can't have objects of wrong type, but outside value
... should be casted, if it can't cast it can't cast
... may be different solutions for different situations

JS: should throw

JL: no

JS: still thinks it should throw

RB: need to make some seperate issues

JL: I think it should be up to the implementor for the special cases

[Opera throws the WRONG_ARGUMENT_EXCEPTION]

<JibberJim> appendChild({}) throws invalid heirachy in moz

<scribe> ACTION: GE to give feedback to the group on issue-23

<trackbot> Created ACTION-78 - to give feedback to the group on issue-23 [on Gorm Haug Eriksen - due 2006-03-03].

<scribe> ACTION: JS to give feedback to the group on issue-23

<trackbot> Created ACTION-79 - to give feedback to the group on issue-23 [on Jonas Sicking - due 2006-03-03].

ISSUE-24

<scribe> ACTION: JS to give feedback to the group on issue-24

<trackbot> Created ACTION-80 - to give feedback to the group on issue-24 [on Jonas Sicking - due 2006-03-03].

<scribe> ACTION: GE to give feedback to the group on issue-24

<trackbot> Created ACTION-81 - to give feedback to the group on issue-24 [on Gorm Haug Eriksen - due 2006-03-03].

ISSUE-25

<chaals> [If maciej could take an action on this it would be helpful - maciej?]

AK: think it should be up to the http spec

JL: existing behaviour, if a location header, follow redirect to stable, if a body, then show

<iand> defer to RFC 2616

<iand> we can't contradict what RFC 2616 says

GE: I think we should give the hole response back to the user

JS: should follow the location if possible

JL: I think it should always follow

CM: is it a good reasson to force

RB: compatibility

GW: would be nice that we do the same thing for all 3xx headers

ID: exception 301 which MUSt ask the user

AK: browsers violate this

RB: you would prefer consistency, but remember that the http spec is written for graphical browsers

ID: not sure if I agree on that

CM: if we say MUST, then no script can offer the body to the script
... therefore no script can pick anything other
... my suggestion is that it's up the developer
... what CM say is that there must be a parser avail

AK: not much you can do with the body

GM: the server doesn't need to provide Location
... at least when you control the server

CM: it's useful to get the suggestion from the server
... ..and meant to be read by a human

ID: what if there is a loop

RB: same for all 3xx

<Zakim> chaals, you wanted to say you can throw the body away

JL: We shouldn't divert from the current behaviour (which is to follow the Location header)

JS: if the implementaiton doesn't follow the Location header we will break
... most people don't care
... even more doesn't know

CM: two possibilities, you get the location header, all follow it, we are not stopping anyone to follow
... if there is not location header, the author need to deal with it or break, if there are use-cases and authors learn to deal with them
... only expose whne the server didn't knew better
... if there is no location the user must do something anyway
... should not prohip the current behaviour, should allow for other implementations

ID: the point is multiple choice, the server doesn't know, let you (the dev) do the selection
... agree with CM

RB: the fact that all do it means that authors relay on it, will break concent
... not follow location is inconsistent
... not a good idea
... we loose information, but we already loose info from the other 3xx codes
... could add a flag in v2 for this

<Zakim> chaals, you wanted to question what happens when there is no location header

CM: the other 3xx doesn't have multiple choices, this is special
... regarding flag, probably a good compromise
... what happens where the isn't a Location provided

JL: today all authors control the site

ID: except the greasemonkey/userjs
... we say that we redirect on all

JL: currently do, so we should stick with that

ID: on a 301 you MUST NOT redirect without an option to the user

[think about this over lunch]

<darobin> JibberJim!

<JibberJim> darobin!

<bjoern> one of our chairs should annonce on public-webapi our new comm policies, I got mail from a subscriber wondering what's going on...

<JibberJim> darobin!

<darobin> yeah, I figured that would happen when I saw the issue hit the list :)

<dino> I was about to do that bjoern

<dino> I was just making a public instance of tracker first

<darobin> ACTION: RB to clean up and send the minutes to the public list

<trackbot> Created ACTION-82 - Clean up and send the minutes to the public list [on Robin Berjon - due 2006-03-03].

<JibberJim> yes bjoern

<darobin> except only the first part, no?

<JibberJim> although I can't see issue 9 so I'm guessing :-)

<JibberJim> I was just minuting what was said

<iand> scribenick: ssire

<iand> scribe: Stefan

Topic 305

305

JS: the security problem with 305 is very obscure

<sicking> https://bugzilla.mozilla.org/show_bug.cgi?id=187996

GE: have we dedcide to mention cross-domain scripting in the spec ?

JJ: not sure where we should mention it

ID: suggest adding a property to tell the browser what to do

<gorm> from whatwg: UAs should set the proxy-related headers according to proxy settings of the environment, and must not allow those headers to be overridden.

discussion about general meaning of UA, GE: UA doesn't mean javascript

ID: we should not force the browser to do anything

RB: browser should give the choice of the to users (prefs)

JS: what are the real cases that lead to 305, not so many

<iand> propose that implementations of XHR SHOULD follow redirects for GET and HEAD if Location header supplied for 3xx responses

GE: one of the option is that browser alsways must follow redirect except for 300 and 305

<JibberJim> I was just minuting what was said- http://10.0.1.4/2006/2/action.1

GE: this is a test for 300

opera and safari doesn't follow it

firefox does

<JibberJim> IE does too

<iand> curl doesn't by default, wget does

RESOLUTION: iand previous proposition approved

RB: we all agree except for 304 which still stands as different

<iand> ACTION: ID to draft text for XHR following redirects

<trackbot> Created ACTION-83 - Draft text for XHR following redirects [on Ian Davis - due 2006-03-03].

GE: redirect from https to http treated as cross-domain security...

<dino> http://www.w3.org/2006/webapi/track/ - public version of tracker - a bit buggier than the buggy member version

GE: DJ: fixed trackbot for tracking public and member mailing lists, so that discussion can go on on boths...

discussion moves to agenda requests

CM: event remapping when context/devices changes... would be nice to have

<chaals> CMN: There are problems in acccessibility, and in using non WIMP interfaces, with mousein/out, mousedown/up where there is no obvious equivalent, or where mouseIn/Out is conceptually (in terms of what the user does) the same as focus, but different in spec and implementation.

SS: is there a definition of focus ?

CMN: CSS says anything that can receive text input

JS: the target of keyboard event...
... proposes topic on focus / blur vs DOM focusIn / focusOut

<darobin> http://lists.w3.org/Archives/Member/member-webapi/2006Feb/0343

CMN: focusIn / focusOut invented to be more generic, but not implemented so much

JS: first possibility is to deprecate DOM focusIn / focusOut

<darobin> http://www.w3.org/TR/xforms/slice4.html#evt-DOMFocusIn

RB: xforms also defines it

GE: the sets of elements it should apply to is also an issue

<bjoern> per http://esw.w3.org/topic/List_of_events SMIL 2.1 has focusInEvent and focusOutEvent and says their DOM2 name is DOMFocusIn, etc.

<bjoern> the SMIL events don't bubble though...

<darobin> RESOLUTION: remove all limitation to HTML element wrt focus

<darobin> RESOLUTION: don't describe how an element may get focus, it's out of scope

<darobin> RB: I think SVG doesn't mind, XForms redefines them, SMIL gets them wrong

<chaals> ACTION: Charles to talk to the WAI-PF group about Issue-32 and what they want - due 2 weeks

<trackbot> Created ACTION-84 - talk to the WAI-PF group about Issue-32 and what they want [on Charles Mccathienevile - due 2006-03-10].

group discusses which events dispatched in Mozilla / Opera...

<darobin> RESOLUTION: We remove DOMFocus*

<bjoern> erm, /remove/ as opposed to deprecate or similar?

RB: do focus/blur bubble ?

<darobin> yeah

<bjoern> k

JS: what's the use case for it ?

RESOLUTION: leave focus / blur as they are, no bubbling but you can always use capture

<bjoern> does this imply that dom3ev implementations do not return true for hasFeature('UIEvents', '2.0') unless they also implement DOMFocusIn/DOMFocusOut?

<JibberJim> they can claim what they want bjoern

coffee break

<JibberJim> everyone should return false for all hasFeatures IMO

<bjoern> that's not what the spec says...

<bjoern> leaving focus/blur as they are, does that mean they are still special html events in the html events module, not generic ones?

<bjoern> or should they be moved to the ui events module?

<Christophe> SVG needs them, so we need them somewhere else than in html?

<bjoern> SVG could just refer to the HTML events module, but I'd think the group resolves to add them to the ui events module...

<bjoern> since having no generic focus/blur events is not a good situation to be in...

<bjoern> the question would then be what the point of having a htmlevents module would be...

<Christophe> ;)

<bjoern> htmlevents would then mean BasicEvents + UIEvents - DOMActivate...

<bjoern> we could make a FocusEvents module...

<darobin> bjoern, "as they are" is wrt bubbling, there's a previous resolution removing all HTMLness

<darobin> so yeah, I would expect they become UIEvents

<anne> bjoern, they have the Event interface...

<anne> bjoern, moving them up to another section would be no problem I guess, not sure about the interface

<bjoern> they may be Event or UIEvent depending or where they come from

<bjoern> "The event types ev:focus and ev:blur may be generated from a user interface; in that case, the event objects also implements the UIEvent interface and UIEvent.view is in use."

<bjoern> we could say they are UIEvents and if they do not originate from a ui, .view is null

<sicking> scribenick: sicking

<darobin> scribe: JS

if focus/blur are generic, we still need to support people passing "HTMLEvent" to createEvent

JS: the issue is that people might pass "HTMLEvents" to createEvent in order to create focu/blur events

<chaals> Bye Ian, thanks very much. See you in Cannes

<bjoern> HTMLEvents is an alias for Event

<anne> "Note: To create an instance of the Event interface for the HTML event module, use the feature string "HTMLEvents" as the value of the input parameter used with the createEvent method of the DocumentEvent interface."

<bjoern> it's more a matter of hasFeature()

<bjoern> dom2?

JL: hasFeature is broken

<bjoern> anne, yes, that's from dom2, the text is not in dom3ev...

<anne> bjoern, right...

JS: another is issue is that ideally focus/blur should be UIEvents

AK: the issues are: wrong interface, conflict with hasFeature
... an implementation of DOM3 events can't implement DOM2 events

RB: DOM3 doesn't say that DOMFocusIn/Out can't be supported

JS: what exactly is the hasFeature issue?

<bjoern> we need to say which module the focus/blur event types are part of

<bjoern> we currently say that's html events

<bjoern> if we make them generic, that does not make much sense

<bjoern> html events is essentially basic events + focus/blur

<bjoern> .hasFeature is defined in terms of the modules

<bjoern> so you can hasFeature(UIEvents, HTMLEvents, ...)

CMN: what is the issue of not making focus/blur UIEvents

JS: they would miss usefull information

<bjoern> as in, proprietary extensions?

<bjoern> the objects for focus/blur just implement Event/UIEvent as per the spec

RB: keep them as part of the html module, but remove everything that's html specific about them

<darobin> RB: and add text saying that HTMLEvents

<darobin> ...is historical

<bjoern> I think putting them in the UIEvents module or making a FocusEvents module would make more sense...

JS: we can't make them implement the UIEvent interface

<bjoern> the spec requires that already!

<bjoern> if they come from a ui

JS: but people aren't calling initUIEvent on them

<gorm> bjoern, it's mentioned in html 4.01 so that would make them htmlevents

<bjoern> how's that different from submit, change, and all the others?

AK: we can make calling initEvent enough

<bjoern> those are basic events, and the htmlevents module inherits them

CMN: what's the downside as keeping them as htmlevents

<bjoern> it'll confuse people...

<anne> bjoern, so you're only concerned about hasFeature, not about the interface they implement?

<darobin> "The event types {"http://www.w3.org/2001/xml-events", "resize"} and {"http://www.w3.org/2001/xml-events", "scroll"} implement the UIEvent interface. All other HTML event types implement at least the basic Event interface. However, they may be generated from a user interface; in that case, the event objects also implements the UIEvent interface and UIEvent.view is in use."

<bjoern> they implement UIEvent or Event, depending on where they come from

<gorm> "The HTML event module is composed of events listed in [HTML 4.01] and additional events which are supported in DOM Level 0 browsers."

JS: the issue is that what people do today is: e = doc.createEvent("HTMLEvents"); e.initEvent; dispatch(e)

<bjoern> HTMLEvents is an alias for Event

<anne> bjoern, the issues is that none of that multiple event interface stuff is in DOM Level 2 Events

<anne> I believe

JS: what they would need to do if we make them UIEvents is: e = doc.createEvent(...); e.init*UI*Event; dispatch(e)

<bjoern> as far as I can tell, you can still use initEvent, the other members would just not be initialized

<bjoern> .view and .detail here

<darobin> http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-eventgroupings-basicevents

<bjoern> (or in case of cEvt('Event'); initEvent(...); they would not implement UIEvent, which isn't really an issue as far as I can see)

<bjoern> (you can make a 'click' MutationEvent if you like...)

JS: so implementors would have to have two classes that both can be focus events

AK: so would non-synthetic events be UIEvents?

JS: yes

AK: so focus/blur would have new fields

JS: i'm not sure i agree that you can create a 'click' MutationEvent

<bjoern> the spec doesn't disallow

<bjoern> neither does it disallow making a DOMSubtreeModified event that just implements Event

grr.. i hate this design

grr.. i hate this design

RESOLUTION: focus/blur are UIEvents
... focus/blur are in the basic event module

<ssire> hasFeature

<ssire> oops typing error

JS: should we say something about what hasFeature('HTMLEvents', '2.0') returns?

<bjoern_h> or hasFeature('UIEvents', '2.0') now that DOMFocus is gone...

<bjoern> good idea for the javascript consoles JibberJim

<JibberJim> DOMFocus isn't being removed from UIE 2.0

<JibberJim> so it shouldn't effect what happens then.

<bjoern> well, the current spec says dom3ev must return true

<bjoern> since it's a superset

<bjoern> it's not more

<bjoern> so it probably should not say return true

JS: ok, so someone could return true for 3.0 and false for 2.0?

JL: yes

RESOLUTION: DOMFocusIn/Out is still required for hasFeatue(2.0) but not for hasFeature(3.0)
... focus/blur is required for hasFeature('UIEvents', '3.0') but not for hasFeature('UIEvents', '2.0')

<bjoern> erm, they are required for BasicEvents, since they are in the basic events module per the resolution above?

<bjoern> UIEvents just has DOMActivate atm

<anne> bjoern, what is unclear?

<bjoern> [16:08] <sicking> RESOLUTION: focus/blur are in the basic event module

<bjoern> [16:17] <sicking> RESOLUTION: focus/blur is required for hasFeature('UIEvents', '3.0') but not for hasFeature('UIEvents', '2.0')

<bjoern> those contradict each other

<bjoern> the resolution would need to be that focus/blur are in the BasicEvents module

<anne> bjoern, some of the HTMLEvents are in basic and UIEvents and that doesn't contradict?

<bjoern> err

<bjoern> that they are in the UIEvents module for .hasFeature('UIEvents', '3.0') to return true

yes

<bjoern> you can't have them in the BasicEvents module and check for them via .hasFeature('UIEvents')

<chaals> why not? It's just another little hack....

RESOLUTION: bjorn updates the spec to do the right thing :)

<darobin> RESOLUTION: bjoern solve the problem

<bjoern> I'll solve it by putting the events in the UIEvents module then...

<darobin> ok

<anne> bjoern, on this side, nobody cares about hasFeature...

<chaals> bjoern, so there would be different homes for them in different versions?

<bjoern> well, in dom2 they are in the HTMLEvents module only

<bjoern> the group then resolved to put them in the BasicEvents module

<bjoern> and then resolved that things should be as if they are in the UIEvents module...

bjoern, I updated my action

(ACTION-18)

next face to face

RESOLUTION: may 1-3, pending everyones ok

F2F #3

<chaals> RESOLUTION: Looking at late August for F2F3

multi-input in pointer devices (or multi-wheel)

JS: which events are affected? can we stick this on UIEvent?

GM: can we use .detail?

RB: no, it's already used for other things
... this might apply to key events too

SS: you can have multiple stylus pointers on a tablet

RB: I'm not sure if this group is the most competent groups to deal with this
... might be better to let MMI handle it

GM: there are shared whiteboards

RB: this is not something that'll show up very soon, but it's something that we don't want to close the door to

<scribe> ACTION: SS to coordinate with MMI to support multiple input devices

<trackbot> Created ACTION-86 - Coordinate with MMI to support multiple input devices [on Stephane Sire - due 2006-03-03].

DJ: it might be enough to stick an attribute on events

AK: an identifying number should be enough

<dino> RB: Let's stop being silly.

DJ: you might need more information then that

<ssire> but some device already got universal identifiers (such as USB device)

remaining issues

<chaals> RESOLUTION: We are going to wait on Stephane for the Issue-33 chaals is about to raise on multiple input devices

<scribe> ACTION: AvK to write a proposal for CSS selector interface similar to DOM-XPath

<trackbot> Created ACTION-87 - Write a proposal for CSS selector interface similar to DOM-XPath [on Anne Van Kesteren - due 2006-03-03].

<bjoern> sounds like we should make the XPath API selection language independent...

<bjoern> Can we close my http://www.w3.org/2005/06/tracker/webapi/actions/13 by saying some other working group should make a spec that defines this stuff, possibly by updating the smil animation errata?

<anne> getElementsBySelector(DOMString Selector, XPathNSResolver)

<anne> it returns a StaticNodeList whatever that is

<dino> --- meeting closed ---

<anne> and XPathNSResolver is an optional argument

<bjoern> optional because that's a pain to implement?

<anne> because of HTML! :)

<bjoern> HTML5 is namespaced, and you could pass null anyway, no?

<anne> that wouldn't much matter for simple CSS selectors