Web API WG Face to face day 2 of 3

2 May 2006


Gorm, MarkB, Robin, Doug, DanZ, Dino, Hixie, Dave, Jonas, Anne, Chaals, Maciej
Robin, Chaals
chaals, gorm, MarkB, schepers


<chaals> scribenick: chaals

Continuing dom3Ev

ISSUE-35 (ISSUE-20 bis) - dispatch state

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

RB: Bjoern made a proposal...

<darobin> bjoern: where's your proposal?

<bjoern> end of http://www.w3.org/2005/06/tracker/webapi/issues/35

RB: Makes sense to me...

IH: Question - create, init, cancel default then dispatch event - does default action trigger?

<bjoern> (not per my proposal)

AvK: You call preventdefault before dispatching?

<bjoern> (this is the first case in http://www.w3.org/2005/06/tracker/webapi/issues/35)

IH: This is related to related event. You ewant to stop propogation there.

JS: For stop propogation makes sense. Don't see what the proposal is for prevent default

RB: Think it makes sense in both cases.

<bjoern> in my proposal calling preventDefault before dispatchEvent is the same as calling it during dispatchEvent

JS: You don't want [something from text]. Yoou want to check if default is prevented after dispatch returns
... common pattern - create, dispatch, checkk if default is prevented. You don't want to prevent before return and it sounds like this is being suggested

<bjoern> that's what the dispatchEvent return value is for

IH: If it has return value, fair enough

JS: Works for me

RESOLUTION: Accept Bjoern's proposal for resolving ISSUE-35

RATIONALE: Makes sense, we can't find a bug (yet... Mwuhahahah)

DOM Content loaded

RB: Bjoern proposes to move for later

<sicking> http://lists.w3.org/Archives/Member/member-webapi/2006May/0000

RESOLUTION: Agreed not to deal with Content Loaded in current spec

RATIONALE: Let us get this spec out - may not be needed anyway

Does dispatch accept foreign objects?

JS: No

AvK: Creted in a nother window?

JS: That you created yourself.
... not using createEvent

<bjoern> you must use createEvent to create events

<bjoern> custom Event implementations are not possible

JS: there is another proposal for creating events. When you create a custom event you can provide a random object

IH: Guess t works

<anne> proposal for custom events: http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-CustomEvent

JS: Problem with accepting foreign objects as events is that we have to extend event interface a lot.
... internally we get/set a lot of flags

RB: Bjoern says we cannot require accepting this unless we allow the implementation to clone the event... (quoting)

AvK: He means creating an event in another document

<bjoern> I note this is about o.contentDocument.getElementById('...').dispatchEvent(document.createEvent()), i.e. Events from a different Document

IH: Should just work

JS: It is the same as moving nodes between documents

IH: One of these things implements interface, another doesn't

JS: Only thing that could be an issue is if different docs have different event objects in same DOM which seems unliekly


<bjoern> If a plugin has its own Event implementation, the plugin host cannot dispatch the object unless the private implementation is shared.

IH: If you can pass the object from one to the other there is no problem

<bjoern> you need to know how to set e.g. Event.eventPhase, which has no setter

JS: We can't dispatch an Adobe event object

IH: You can't get hold of it to pass in the first place.
... so not a problem - it can't work anyway.

RB: You could clone it...

IH: If you get hold fo something with the right interface it should work.

<bjoern> surely IE and ASV can share objects if ASV uses the IE script engine?

JS: Problem is that we have to extend NSIevent to make it workable
... Across documents in the same DOM it should work, across documents with different DOMs it may not work

IH: Agree.

DS: Related issue was broughht up by CDF

MJS: didn't they remove auto X-doc flow?

RB: We can say that implementatiopns may do it.

AvK: Why not require it.

IH: If you have some but not all implementations doing it, you lose interoperability

RB: Does it need to be all, or can it be all CDF only

MJS: Think it is better to be all or none.

<bjoern> +1

MJS: if you have a plugin with its own DOM, the hosting implementation won't be able to dispatch - implementations depend on extra internals to work.
... Cannot require between arbitrary DOMS, but inside one makes sense

RB: Think it makes sense inside one DOM implementation

MJS: What about where event targets are not DOM nodes?

<bjoern> (hmm, the main problem with cloning would be that you need to know the interface the Event implements, and support that interface...)

MJS: event Targets may not have owner documents anyway...
... e.g. XHR

IH: XHR is always associated with a window, which has an owner doc...

RESOLUTION: We require it within the same DOM impl. across different DOMs it MAY work.

IH: If smeone does the may case, it will eventually become a must.

CMN: That's a bad thing?

IH: Painful to implement

MJS: Would prefer MUST or MUST NOT

<bjoern> me too

RB: If someone wnts to do it they will anyway. So don't think MUST NOT is something we can enforce.

<bjoern> say that applications must not rely on it?

<bjoern> and give an example of how to do it?

GE: How should it work in cross-domain? (currently done differently)

CMN: It is a security issue that can be dealt with by browsers.

JS/IH: You shouldn't be able to do that.

CMN: Think we should stick with MAY. Don't want to race into it, but there is no reason to forbid it.

MJS: So why not make it MUST?

CMN: It's a pain to implement.

IH: You can't do lookupbyname in C++ interface.

<bjoern> I think it's close to impossible to implement, until the plugin interfaces get changed to specifically make that possible

MJS: You have to be able to get to the javascript binding and pass it to dispatch, so it should be doable by copying

JS: It is doable technically, but if someone invents a new interface, it may become impossible

DS: What's wrong with a may?

<bjoern> authors will rely on it if it works

MJS: May leads to interoperability problems.

<bjoern> We ran into this problem when Anne wrote the CDF x-doc eventing text

<bjoern> (or a part of it)

<anne> bjoern, that's easy to revise, the problem is that it's possible already, not that I wrote some sample code for it

CMN: Think that MAY makes sense for the way the market develops

<bjoern> yes, the point is that it's easy to make mistakes here

MJS: This is simiar to (analagous problem that scribe missed)

JS: This seems like a way edge case that won't create real problems.
... things don't generally work, but if someone makes it happen, that seems to be somethign OK.

<bjoern> http://www.w3.org/2004/CDF/specs/CDR/wp-1/cdf.html#event-propagation has the current CDF x-doc eventing text

<bjoern> [[[

<bjoern> var x = document.createEvent("CustomEvent");

<bjoern> x.initCustomEventNS("http://example.org/test", "test", true, false, null);

<bjoern> window.frameElement.dispatchEvent(x);

<bjoern> ]]]

JS: there are much bigger interop problems than this one. If we have this with events we should define it for everything else too...

RESOLUTION: We are happy with this being a MAY (even though we are not keen about them in general)

is createEvent case sensitive

RB: Agree with Bjoern

AvK: Not what implementations do

JS: Not used much, but people who do use it depend on it.

AvK: Think interface names are case-insensitive

<bjoern> they are not most of the time...

IH: Legacy implementations only support events. We can make that CI

RB: SVG implementations are generally C-S

<Hixie> "only support legacy event names"

IH: Seems wierd to make it CI

<Hixie> as opposed to interface names

DS: How much does that add to parsing

JS: virtually nothing.

DS: I copied code and misunderstood case-sensitivity. Does it cause a problem to have C-I

JS: We are C-I on all interface names.

RB: Bjoern says we need to define algorithm for uppercasing

CMN: i18n issue?

JS: No problem - we only do ASCII

IH: there are issues - ASCII and Unicode uppercasing are different on chracters in ASCII range.

MJS: So let's use ASCII algorithm since in practice IDL already constrains us to ASCII

RESOLUTION: Case Insensitive, using ASCII uppercasing algorithm


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

<bjoern> so does this mean non-ascii iface names are disallowed? or that you make c-s comparison for non-ascii iface names?

<Hixie> c-s

<Hixie> but in practice they aren't allowed by IDL

<Hixie> according to maciej

<bjoern> we have no requirements for createEvent argument naming

JS: support proposal

<Hixie> createEvent() takes an interface name. Interface names are defined by IDL to be ascii-only, according to maciej.

<bjoern> well, there is no requirement that you can use IDL iface names only

<Hixie> well for those it's c-s

<Hixie> except for ascii characters

CMN: Where does activate fire in dblclick?

<bjoern> right, I'll just write some text.

JS: should dblclick dispatch on 4 clicks?

AvK: Yes - this actually happens in implmentations on Mac

IH: dblclick should fire every time you have an even number of clicks.

JS: Why does cancelling 2nd click not cancel dblclick?

AvK: cause that's what implementations do.
... makes sense to me.

JS: No strong arguments, but doesn't seem intuitive to me.

RESOLUTION: We accept Anne's dblclick proposal

RATIONALE: It works, people use it, we fund no bugs.

<darobin> http://www.w3.org/2005/06/tracker/webapi/issues/51

JS: does === work for numbers in javascript?

MJS: yes. So doesn't matter for spec.

JS: matters for test case.

MJS: but doesn't break it. We don't need to go there.

mobile keys

<darobin> http://lists.w3.org/Archives/Public/public-webapi/2006Apr/0306

<darobin> http://www.w3.org/2005/06/tracker/webapi/issues/51

<bjoern> my comments at http://lists.w3.org/Archives/Public/public-webapi/2006Apr/0321

JS: When I left dinner there were "engaged discussions" on this.

RB: Issues - should they be mapped to common desktop keys? SHould the longpress be seperate or keydown/up modifier?

AvK: Do we need to say anything about it?

RB: If we start making mappings, we risk getting them wrong

AvK: Making it explicit for mobiles is problem. default actions are different on mobiles

IH: True, and on browsers...

JS: Would argue that intuitively that numpad on phone/desktop should be the same. I would want to see an application wehre you want them to do different things.

RB: For numkeys, joystick, soft keys, that's a bit ugly - especially soft keys.

CMN: Think it is not a good idea to define mappings at same layer as primitive events. Soft keys, are clearly not easy, accessibility technology may show use case for not mixing numpads (which are the most intuitively obvious mapping)

MJS: Other than numpad, is the set of keys on phones consistent enough to consider any mapping? There are two issues in mapping. By default, if you don't look for the different things will they get triggered. And can you tell the difference if you do go out of your way?
... it is possible to get a number, and then find out where it came from if you want it.
... accessibilitytechnologies aren't implemented as javascript in the browser.

DS: Saying what the source is as part of the property of an event is sensible.

<bjoern> (procedurally I'd like us to come up with a new proposal and have it reviewed by mmi, di, wai, and others before we come to a definite conclusion)

DS: I think it is better to have some default behaviour across implenmentations. If people are autoring for hpones I think it is less likely for teh content to work as the web eveolves if there is no mapping.

IH: Agree

<mjs> fwiw my phone has OK, Menu, Talk, End, Back, Camera, and up/down/left/right buttons

<mjs> I have no idea which of these are "the soft keys"

JS: Seperating keypad is like click event - it is desirable to have the event triggered by keyboard as well, but be able to tell the difference.
... have default behaviour the same, lt you pick differences.

MB: For existing content, authored to use events not available on one or other platform, it drives a split in interoperability

<Zakim> darobin, you wanted to speak about how we decide where the cut-off point is for mapping/not mapping

RB: First question - are phones similar enough? generally yes - there is a common subset. DOM already accounts for various things that are only avalable sometimes.
... mapping with flags will get it wrong with one-device content, they will get the wrong event because they don't look.
... problem is that we are trying to abstract, but in a half-arsed way. If we want events to work cross-device, we need another layer that gets it right.
... at the moment i think we are making it up as we go along. Don't think it is a good way to go.
... all the arguments about making it easier to get things right with current content are the same arguments for why it owuld not work.
... You have different interaction modalities, so your UI is different

IH: we are talking about cases where the author worked to one device and there is nothing else to go on.

<anne> Hixie said more or less what I wanted to say.

DS: if someone starts bad, that's going the wrong way. Mobiles are entereing into the web at large. I want their content to work as well as possible with browsers.

RB: UI designed for 176x208 screen on a highdpi screen is going to suck, too.

adjourned for 25 minutes

<darobin> scribenick: gorm

<Zakim> chaals, you wanted to note that some access technollogies are implemented in browser, but it is indeed not somethign I have a strong use case argument for and to say we can ask for

<schepers> DS: not for all UIs

CMN: dont think we should do mapping by defining low level events
... leads to same problem as click & activate
... it's a sensible approach to give the responsibility to the implementors instead of building an abstraction layer
... should not map at the moment

JS: seems like we want to make different applications and therefore got different solutions
... some people only use one browser and some try to design for multiple platforms

RB: I think you are trying to solve the probem at the wrong layer, interoperability is the goal, but doing a device specific mapping is the wrong solution to the problem
... should do it the lowest level which is key input

JS: people use DOM events directly so that the labstraction layer

MJS: today browsers use DOM 2 key codes

IH: keyCode is not defined in any specs

DS: how about Chinese

MJS: use txt input events
... IH suggested use the same identifier then make a flag for the device
... second suggestion use the same keyCode but a different keyIdentifier

RB: existing content will work with keyCode

MJS: we do mappings on keyboards today
... already abstraction on semantically same keys today
... today the window desktop is the standard would be better to map than making your own

DS: we are not talking about existing content, but future content

<Zakim> chaals, you wanted to say it does sound complicated. But the reason why text events are so complicated is that they didn't work the other way around. There are ongoing difficulties

<anne> I'd like to have the keypress event and charCode and keyCode etc. in a standard... that's actually what is needed

<bjoern> that's not so clear to me anne...

CMN: It's a nightmare to implemenet accesibility..text input is simple and painful

<anne> bjoern, well, browsers have to reverse engineer each other for that and as mjs explained also across platforms etc.

CMN: high level of complexity
... need a way of handling existing content, but the future content is more important
... today you must do some clever implementation and that is reality
... trying to do the mapping things has failed in the past and will fail in the future

DS: What about giving them seperate events with suggested mappings for a subset of the most common keys

CMN: it's useful to give some guidance, accesskeys in HTML is a good example of how dumb things can become

<bjoern> (Sounds like it might be a good idea to find someone to make a note on how authors who want to do the right thing deal with "keyboard" input...)

DS: lets see what people think about it

IH: do concrete proposal

RB: like the idea of public opinion

<darobin> ACTION: IH to make a public proposal on the softkey issue

<trackbot> Created ACTION-164 - Make a public proposal on the softkey issue [on Ian Hickson - due 2006-05-09].

<darobin> ACTION: GE to make a public proposal on the softkey issue

<trackbot> Created ACTION-165 - Make a public proposal on the softkey issue [on Gorm Eriksen - due 2006-05-09].

<darobin> ACTION: DS to make a public proposal on the softkey issue

<trackbot> Created ACTION-166 - Make a public proposal on the softkey issue [on Doug Schepers - due 2006-05-09].

<darobin> ACTION: RB to make a public proposal on the softkey issue

<trackbot> Created ACTION-167 - Make a public proposal on the softkey issue [on Robin Berjon - due 2006-05-09].

<darobin> RESOLUTION: if someone wants to write a Note with best practices for keyboard handling, they are more than welcome

<bjoern> action on you to propose this in the hcg/to mmi/di/... :)

RB: longpress should it be a seperate event or modifier?

JS: e.v. to longpress 2 for getting the number

<bjoern> my comments http://lists.w3.org/Archives/Public/public-webapi/2006Apr/0321

JS: need to events

<darobin> IH: you would get keydown, keypress, new event (keyhold/longpress), keyup

<darobin> JS, RB: agreed

<darobin> the colour of the shed is: keylongpress

<darobin> RESOLUTION: we have keylongpress as a separate event with the same everything as keypress

<darobin> bjoern, do you want me to redraft or can you integrate?

<bjoern> redraft

<dino> ISSUE-55

<sicking> http://www.w3.org/2005/06/tracker/webapi/issues/55

<bjoern> I would need to know at least when it occurs (just once, every n seconds while the key is being pressed, ...)

wheelDelta DOM attribute for mousewheel event

<darobin> ACTION: RB to redraft keylongpress based on discussion

<trackbot> Created ACTION-168 - Redraft keylongpress based on discussion [on Robin Berjon - due 2006-05-09].

<darobin> bjoern, that didn't get minuted, but the answer is once

AvK: didn't come to a resolution on horizontal wheeling..no resolution yesterday

IH: I tried to use related event, but it didn't work

IH: you have to make sure you only get one event, but you would like to listen t oboth

DS: what about doing it like it's done today (mousewheel) with an extensible new event

JS: could do 3 events, mousewheel, mousewheelx and a superdupermousewheel

MJS: ; also suggested that
... a generic mouse events that can be extended

DS: if the xdelta or ydelta you can set it to zero if the event was canceled

AvK: you can cancel vertical scrolling by setting the xaxis to 0

<Hixie> so the proposal is to fire first mousewheels, whose default action is to fire mousewheel and mousewheelx as appropriate, and the default action of _those_ is to scroll.

DS: you could say wheel.x.cancel()

IH: if you would like to deal with the diagonal you would listen to the first and cancel all events
... if you only would like the horizontal you would only listen to that and cancel all the others

<bjoern> does "scroll" include "move slider to the left/right"? if not I'd disagree with that default action.

MJS: Suggestion 1.) The wheels event with the default action to dispatch the wheel and wheelx event 2.) The wheels event with the readwrite x/y delta
... both should fire when delta != 0
... 3.) wheel and wheelx with both x and y delta

IH suggestion 3 is to confusing

DS: I think the 3 event solution will satisfy the SVG working group

IH: suggestion 1 is the only one which makes sense

JS: whats the point of preventing vertical scrolling
... ?

IH: e.g. you might want to cancel them for games

MJS: the most questionable is when you would like to prevent horizontal scrolling and vertical is ok

IH it's the same thing

MJS: would simplify the model if we said we didn't want to handle this use-case

RB: we can add teh use-case later

MJS: can remove the wheelx and handle that later when the use-case is clear
... should descide if we go for hte prevent horizontal scrolling usecase
... what about wheels and wheel

IH: just as confusing

JS: should have mouse because it's a pointer
... in many mousedrivers you can specify if the wheel is physically attached to the mouse and the behaviour

<anne> mousewheeling!

CMN: if your keyfocus is in a textarea and your mouse is somewhere else it can scroll the textarea

IH: it's still a mousehweel

JS: *I agree we should call it a mouse

<darobin> ACTION: Maciej to draft fraggle rock event (mouse wheel)

<trackbot> Created ACTION-169 - Draft fraggle rock event (mouse wheel) [on Maciej Stachowiak - due 2006-05-09].

JS: mousewheels should always be fired

<mjs> RESOLUTION: we will use a 2-event solution, with the existing y-only "mousewheel" event firing as default action of a general n-dimentional wheel event

RB: yes

<anne> 1. wheel

<anne> 2. mousewheels

<anne> 3. mousewheeling

<anne> 4. mousemultiwheel

<anne> 5. mousemightywheel



<mjs> MouseSquareWheel

<schepers> ReinventingMouseWheel

<MarkB> MightyMouseWheel ?

<bjoern> post to public list, asking for proposals

<bjoern> I like MausRad ...

<MarkB> we're hungry, and won't get lunch until we pick one!

<arun_> MouseWheelN

<bjoern> mouseuniwheel

<bjoern> mouseomniwheel

<anne> bjoern, serious?

<bjoern> which one?

<anne> bjoern, either

<arun_> i like the sound of mouseomniwheel

everyone voted against asking on the public list, sorry Bjoern

<anne> everyone voted against not starting with mouse too

<anne> bjoern, if so, we might consider it...

<bjoern> all my suggestions are serious

<darobin> RESOLUTION: mousemultiwheel

<mjs> Hixie, khtmlHorizontalmousewheel

<Hixie> thanks

<Hixie> and what's the attribute?

<bjoern> the names should be on http://esw.w3.org/topic/List_of_events

<Hixie> .detail?

<mjs> Hixie: same interface as mousewheel, I believe

<mjs> so wheelDelta

<anne> mjs, doesn' work

<mjs> (and I guess also detail)

<MarkB> scribenick: MarkB

Effect of evt.currentTarget.add/removeEL

<Hixie> mjs: http://damowmow.com/playground/demos/mouse-events/wheels/001.html

JS: issue is; if a listener is added while events are firing, should it receive event?

did i get that right?

<Hixie> bjoern, fixed, thanks

<mjs> Hixie, works, but the line is red

<Hixie> good to know that our event name is so great that the VERY FIRST use of it involved a typo

<Hixie> mjs - that means you don't support the multi one

JS: specs says removing listener takes effect immediately, adding one doesn't

<Hixie> either that or safari is backwards

JS: i can understand that logic

<anne> Hixie, perhaps make the test IE compatible and check it there?

JS: inconsistency is confusing though

RB: easiest to implement is add when added, remove when removed

JS: don't think so - listener lists are copied

<bjoern> (there might well be code that depends on deferred adding)

MB: does this effect interop?

AVK: in theory

JS: DOM 2 is clear. if we change it, we're breaking DOM 2

<bjoern> (it doesn't matter much to "break" a spec if implementations ignored the spec...)

AVK: propose that both add and remove don't take immediate effect


AVK: I would like to know what implementations do

<bjoern> that's in http://www.w3.org/2005/06/tracker/webapi/issues/77

<bjoern> I could not find an impl that doesn't do deferred adding

<anne> bjoern, you have testcases for adding and removing event listeners on "not the current target"

<bjoern> not online

<Hixie> can someone with IE _and a mouse wheel_ tell me if this works?: <!--[if IE]><script type="text/javascript" src="excanvas.js"></script><![endif]-->

<Hixie> er

<Hixie> can someone with IE _and a mouse wheel_ tell me if this works?: http://damowmow.com/playground/demos/mouse-events/wheels/001.html

<Hixie> specifically, does the line go up or down when you scroll down

<bjoern> exception line 26 col 6

<bjoern> unsupported method/property

<anne> Hixie, what line?

JS: I like doing it immediately. simplest to specify and understand. shouldn't be hard to implement.

<Hixie> bjoern: um

<Hixie> bjoern: does it say where that is?

<Hixie> col6 is in the middle of an identifier whatever the line

<bjoern> well, I guess it doesn't like addEL

<Hixie> oh

<Hixie> sigh

<bjoern> I gave the line/col above also...

<bjoern> just what it tells me

MS: could be hard to implement. imagine removing a listener then adding it again

<Hixie> ok well someone else can make it work on IE

MS: don't want event fired twice

<anne> Hixie, http://testsuite.org/dom/events/types/mousewheel/001.htm (Opera seems backwards indeed...)

MS: let's pick model which is easiest to implement

<anne> Hixie, no expected results whatsoever

<anne> Hixie, I guess it's a regression we have to fix

<Hixie> i have no idea what that test is doing

JS: if you add a listener, it makes sense that it will receive the event
... i don't see any arguments that this is so hard to implement. opt for simpler explanation.

MS: explanation would have to take into account the sequence and firing order

<anne> Hixie, what I said

MS: so not so simple

JS: for remove, just need to say no more events will be received

MS: i think the argument that nobody has implemented the spec, is a good reason for not following what it says

right maciej?

<mjs> MarkB, yes

AVK: removing or adding listeners should not have effect for the current dispatched event

JS: both adding and removing should take effect immediately

both of those were proposals

MS: prefer Anne's proposal

<bjoern> Both work for me, very minor preference for Anne's

<anne> (both are about the current target)

<bjoern> (keeping the spec as is works for me aswell)

MB: do we need to say anything at all?

All: erm, yah

RESOLUTION: accept Anne's proposal, "removing or adding listeners should not have effect for the
... current dispatched event

pressure sensitivity for tablets

CMN: Ink group has experience with this. not getting a lot of pressure to put it in. MMI hasn't asked
... suggest deferring

RB: also angle pressure, distance, modifiers... complex

<bjoern> (I use a tablet to navigate every now and then, wouldn't appreciate the "buy another tablet" ads...)

JS: does this only event mouseclick?

CMN: relevant to lots of events

DS: how quick would MMI move on it?

<darobin> ACTION: DS to talk to MMI/Ink about pressure

<trackbot> Created ACTION-170 - Talk to MMI/Ink about pressure [on Doug Schepers - due 2006-05-09].

DOM3EV: Which events are fired for name mutations

RESOLUTION: deferred pending ACTION-170

<bjoern> I thought dom3core was clear that you get all the events, no matter whether you clone the node or not...

<bjoern> but I didn't check the discussion yet.

<bjoern> IMO, this should be Core errata, not in Events. core defines the renaming feature.

IH: who wants mutation events?

JS: adds lots of complexity
... alternative is to forbid mutation of the tree while mutation events are firing

<Hixie> only three and a half people put their hands up when i asked who wanted mutation events

<anne> and none of them implement stuff

<anne> (well, browsers)

<bjoern> I guess the numbers would be a bit different is the question would be who think apps should be enabled to act in response to tree changes...

<chaals> [I think bjoern is correct]

lots of discussion about complexity of mutation events

DS: I want functionality of mutation events - don't care how its accomplished

<bjoern> (I think if we want to make major changes in this regard we should have proposals and discuss on the list first)

<darobin> ACTION: Maciej to make a proposal to change mutation events such that they are easier to implement [recorded in http://www.w3.org/2006/05/02-webapi-minutes.html#action09]

<trackbot> Created ACTION-171 - Make a proposal to change mutation events such that they are easier to implement [on Maciej Stachowiak - due 2006-05-09].

JS: internally, use a notification mechanism. not event based. not DOM. no bubble/capture. not allowed to mutate DOM. in theory, could expose it.

IH: heard other people asking for the ability to lock the tree
... should we offer that?

<darobin> ACTION: JS to make a proposal for lock-down of the tree during mutation events [recorded in http://www.w3.org/2006/05/02-webapi-minutes.html#action10]

<trackbot> Created ACTION-172 - Make a proposal for lock-down of the tree during mutation events [on Jonas Sicking - due 2006-05-09].

<Hixie> would raise NO_MODIFICATION_ALLOWED_ERR if you attempt to mutate the DOM while the tree is locked

DS: if we're going to allow for locking down the tree, need to make sure that it can't get stuck in locked mode

RB: I have content that would break if tree was locked during mutation dispatch

<bjoern> me too

RB: issue is, when renameNode is called, what events should be dispatched?

<bjoern> renameNode is at http://www.w3.org/TR/DOM-Level-3-Core/DOM3-Core.html#core-Document3-renameNode

DOMElementNameChanged would fire

IH: DOMElementNameChanged would fire

JS: setAttribute

<bjoern> "When the node being renamed is an Attr that is attached to an Element, the node is first removed from the Element attributes map. Then, once renamed, either by modifying the existing node or creating a new one as described above, it is put back."

<bjoern> seems clear that you should get the removed/added attr mutations...

<bjoern> (of course, if you cannot simply rename)

<gorm> is this the latest? http://dev.w3.org/cvsweb/~checkout~/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-eventgroupings-mutationevents

<bjoern> yes

<Hixie> we're saying calling renameNode would squash all the other events

<Hixie> and just send a namechange event

<gorm> bjoern, do you need to implement mutation events to claim conformance?

<Hixie> with relatedNode set to the other node if necessary

<bjoern> to dom3ev, no; to the mutation name events module, yes

<gorm> ok

<bjoern> same for all other modules

<bjoern> "An implementation is DOM Level 3 Events conformant if it supports the Core module defined in [DOM Level 2 Core], the DOM event flow and the interfaces with their associated semantics defined in Basic interfaces."

<darobin> RESOLUTION: renameNode only fires the name mutations, no matter how it's implemented inside

<sicking> RESOLUTION: relatedNode for MutationNameEvent should be set to the old node when a new node is created

<gorm> bjoern, the mutation events is not in the basic interfaces?

DOM3EV: Specifying inappropriate modifiers to initMouseEventNS

<bjoern> no

IH: some implementations use a bitmask

<bjoern> I think we should not require lexical checks for these; I don't mind optional checks.

RB: don't really care, but if you pass a string it should be propagated

RESOLUTION: modifier is a string

<darobin> RB: it's Cam's option B

DOM3EV: MouseEvent.client[XY] clarification

<darobin> http://lists.w3.org/Archives/Public/public-webapi/2006Apr/0356

AVK: relative to viewport or canvas?

JS: viewport, i believe

<anne> Hixie, roc?

MS: four sets of xys - complex

<darobin> RESOLUTION: deferred for testing

<anne> http://www.w3.org/mid/op.s6p3wyy064w2qv@id-c0020.oslo.opera.com

<bjoern> so who got the testing actions?


<darobin> bjoern, mjs is testing now

<bjoern> don't forget to include SVG tests...

IH: if you turn off key repeat in the OS ...

back to XY for a minute ...

<darobin> RESOLUTION: make clairification that clientX/Y are relative to the viewport of .view's origin

RB: do we want to specify the other kinds of XYs?

<darobin> ACTION: GE to make a proposal for the other X/Y things like clientX/Y

<trackbot> Created ACTION-173 - Make a proposal for the other X/Y things like clientX/Y [on Gorm Eriksen - due 2006-05-09].

back to keypress

AVK: do we want to figure out how charCode and keyCode work? reverse engineer IE?

<bjoern> -1 for dom3ev, fine for some other spec.

MS: all Mac browsers give Windows charCode/keyCode values

CMN: people use keypress

RB: do we do it in dom3ev or a separate spec?

<bjoern> (including keypress doesn't hurt much, but the legacy context info I'd rather not at this point)

<darobin> ACTION: DS to specify keypress, keyCode, charCode

<trackbot> Created ACTION-174 - Specify keypress, keyCode, charCode [on Doug Schepers - due 2006-05-09].

RESOLUTION: we will do keypress/keyCode/charCode

<chaals> RATIONALE: Because we have to...

<schepers> also, the dispatch order


<darobin> scribenick: schepers

Abstraction of Events in DOM3

JS: that depends on the scope...

click is abstracting the mouse...

scribe: I think it's a good idea to have low-level events triggering higher-level events

RB: more concrete triggers more abstract

IH: you said it's not possible to solve the abstraction at the physical layer
... but the DOM3 layer *is* the abstraction layer

RB: I just don't want to go any further up

IH: I have 2 use cases

<darobin> http://www.w3.org/2005/06/tracker/webapi/issues/79

in one application I want ctrl+ and ctrl- to be able to be detected, regardless of which + or - key it is

2nd, ctrl= and ctrlshift= to have distinctive events

<Hixie> ack

<Hixie> the two cases were ctrl-+ and ctrl-- vs ctrl-= and ctrl-shift-=

RB: I understand the use case, but don't know how it can be solved...

<Hixie> bearing in mind that -/+ are sometimes on the same key and =/+ are sometimes on the same key

MS: I have a suggestion

MJS: the way we do this in the Cocoa framework, we have character and character-ignoring modifiers, and the modified-character

GE: there can be different keyboards...

MJS: it's not a fixed keyboard, it's based on the OS' keymap

<scribe> ACTION: MJS to write up proposal for abstracted key events [recorded in http://www.w3.org/2006/05/02-webapi-minutes.html#action13]

<trackbot> Sorry, couldn't find user - MJS

<scribe> ACTION: maciej to write up proposal for abstracted key events [recorded in http://www.w3.org/2006/05/02-webapi-minutes.html#action14]

<trackbot> Created ACTION-175 - Write up proposal for abstracted key events [on Maciej Stachowiak - due 2006-05-09].

Resolution: defer pending Maciej's proposal

Origin of the event (Issue-10)

<gorm> http://www.w3.org/2005/06/tracker/webapi/issues/10

AVK: we would have to distinguish between various mouse devices...

<anne> (my laptop has two pointer devices and I have this mouse attached which has another one...)

<anne> (all different origin)

<darobin> CMN: are you expecting that you would be able to differentiate if there's no chance to produce that key without shif

<darobin> IH: I'm happy with that

Resolution: defer issue-10

<anne> Selectors API FPWD!!! Selectors API FPWD!!! Selectors API FPWD!!! ...

[talking about agenda items and ordering]

Deliverables and Status

JS: DOM3 XPath needs to slide back a month

RB: persistent storage is supposed to be this month
... this is Ian Davis... haven't heard back so it's presumed to be on track

MJS: is there some direction for this?

JS: Mozilla is going to implement Persistent Storage as defined by WHATWG

CMN: Drag-n-drop is on track

RB: progress events is being worked on

<mjs> Here's the IE persistent storage (I think): http://msdn.microsoft.com/workshop/author/persistence/overview.asp

<mjs> is there a reason not to use this instead of the whatwg one? (I haven't read over it at all so I don't know if it is any good)

GE: have you done work on Global?

IH: please send me what issues you have on WHATWG specs

<chaals> CMN: progress events is on track.

RB: I will put out the SVG file upload events and you can comment on it, Jonas

<mjs> from my quick read over it, I don't see any obvious problems (the IE persistent storage), however from that example I can't tell if it is tied to behaviors

<anne> I think this was about file upload, not SVG progress events...

<mjs> Hixie, would love to hear the short version of what is wrong with the IE one, mainly because I fear having to implement both the IE model and the whatwg model if Moz implements that

RB: that covers the ones due soon

<anne> proposal draft: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/draft/selectors-api.htm?content-type=text/html;%20charset=utf-8

AVK: Property Selectors spec is ready for publication

RB: what about dates for publication

CMN: if it's in CR and it's not implemented, it should be sent back
... I don't want to hold up XHR

AVK: this won't hold it up

IH: are implementors interesting in implementing it?

JS: I'd acccept a patch

IH: when I asked around, implementors said it would be too slow

<mjs> MS: I would be interested in implementing it, I think the static list and single-element versions make it easier to implement efficiently, and I have heard from content authors and JS library authors that such a thing would be desirable

Resolution: request publication of Selectors API

RB: we've also had proposals for Security Exception and the Super-Style API

IH: it's this more than a initial number?

<anne> Super-Style API being CSSOM?

IH: last I heard, CSSOM was supposed to be CSS? Who has it?

<Hixie> ACTION: IH to suggest a security exception

<trackbot> Created ACTION-176 - Suggest a security exception [on Ian Hickson - due 2006-05-09].

RB: it's not on our list of deliverables

MJS: I have 2 more we need to talk about:

1) text selection

2) editing

CMN: selection is important for drag-n-drop

IH: you can do them separately

CMN: yes, but it's not ideal

JS: one problem is that it can be multiple ranges

<anne> see here for selection: http://whatwg.org/specs/web-apps/current-work/#selection

MJS: I don't care which of IE or Mozilla is done, we just want one to be standardized

DJ: with all these new APIs, what does Microsoft think?

<Hixie> wow. i actually did spec this.

<Hixie> http://whatwg.org/specs/web-apps/current-work/#selection

<Hixie> looks like IE's version, i guess

<Hixie> hm, or not

<Hixie> might be mozilla's

RB: if anyone else has contributions, you can submit them

MJS: I don't think selection should be in the same spec as dnd

RB: anything else?

MJS: XSLT processor

JS: my plan is that one XPath is more done, I will follow that same process


MJS: I posted a bunchof issues to the list
... the only interesting controversy was timers
... others were all positive
... so I should close those

RB: let's talk about them a bit
... Issue-38: Alert, etc. on Window is closed
... Issue-59: history: closed

<anne> see: http://www.w3.org/2005/06/tracker/webapi/products/4

<chaals> RESOLUTION: Window should include history

ISSUE-60 Should Window Object 1.0 include access to frames by name (window.frames)?

Resolution: ISSUE-60 deferred

ISSUE-61 Should the Window spec drop any conformance requirements for AbstractViews besides the defaultView?

MJS: summary: if we support multi-view, and it supports windows, should we have other requirements on them?

IH: there is only one implementation that is close

MJS: so, I will make it optional, and all requirements are only on default view

Resolution: all requirements are only on default view for ISSUE-61

<Hixie> issue-63 is resolved the same way as issue-61, fwiw

ISSUE-64 Should the Window spec define Window's place in DOM event flow?

AVK: I think it makes sense to have it in the first version

<bjoern> implementations are rather buggy and have surprising behavior, last time I checked.

MJS: I'd rather not specified events, but that it takes part in the event flow and that it's an event target

JS: this would break content for load events

<bjoern> +1 on being an event target; for other things I'd like to see a proposal first.

JS: this ends up firing multiple times if there are images
... our solution is that the window does not participate in the event flow for load events

GE: what about iframes?

JS: there will be a load event, but the outer window will not be notified

<chaals> RESOLUTION: Window participates in capture/bubble before/after documment, but is bypassed by load events.

ISSUE-65 Should Window spec add parentWindow property to documents?

Resolution: yes, add parent window

ISSUE-66 should Documents that aren't being presented be required to have a null defaultView?

Resolution: yes, but it's complex

ISSUE-67 Should resolution of relative URI references sent to location be defined in JS bindings or generally?

MJS: there are a lot of these, but they are strange in JS

IH: actually, it's sensible

MJS: what about how it works for other languages? most people think it should be absolute URIs

RB: in SVG, the Java knows about the Window

MJS: I don't think it can work... Java doesn't have a global scope

CMN: does it make sense to generalize this to those languages that have this scope?

<darobin> RESOLUTION: we could say in the spec "resolution of relative URIs, if supported, is dependent on the binding", in the ES binding we specify it, and if there's a new binding we'll deal with it

ISSUE-68 What to do about window.location.toString()?

<mjs> RESOLUTION: string conversion rule is only for ECMAScript, defined in language bindings

ISSUE-69 Should Location.reload() take an optional bool argument to force reload?

MJS: I don't know what implementations do

GE: what's the use case

RB: it's not a strong use case

JS: we do allow an optional argument, and if true, we act as shift-reload and bypass local cache and any proxy caches

MJS: it shoud be allowed and probably required, but I dont' think we shoud dictate behavior

IH: something else is that if calls reload while resize, it shouldn't reload, it should redraw... Netscape had a bug

JS: it isn't impossible that people depend on the caching

MJS: force reload should defer to the server

<dino> I can make the minutes again

<dino> otherwise it probably includes the end of yesterday as well

<darobin> RESOLUTION: if the browser supports a force reload operation, calling reload(true) will have activate it in place of the vanilla reload

<bjoern> you should remove the post-meeting discussion from yesterday from the minutes then

ISSUE-70 what to do about window timers?

MJS: this is a different proposal than ISSUE-37
... the problem is that the widely-implemented time only makes sense for JS

IH: you can do what IE does
... or you could have an arbitray DOM closure

RB: I don't think this is a problem
... if it doesn't make sense for *your language*, don't do it

GE: this is a pain for the "this" operator

MJS: do we make a generalized interface, make it only for JS, or make it only JS and define a generalized one for the others

RB: it's already planned to make a new better timer interface, but it shouldn't be part of Wndow

<bjoern> some people expressed disagreement with that plan, I think...

IH: I strongly object to adding a new timer to JS, since the Web API is already getting too big

RB: let's split this into 2 discussions

MJS: if we do something, we should do it once, right.
... the simplest thing to do to make a simple extension that also works in Java

GE: this isn't compatible for EcmaScript Mobile

<mjs> MJS: extremely simple version of how to make it also work for Java: where the ES versions take a string or function, you have a TimerListener interface...

<mjs> MJS: the TimerListener interface has a single timerFired() method

<mjs> MJS: for Java, you pass an object that implements it

<mjs> MJS: for ECMAScript, you can *only* pass a string or function, and the ES language bindings define how they map

Resolution: we follow Maciej's proposal

Publishing Window

RB: when can we publish this

MJS: I've added some stuff, but I'd like to have it feature-complete... end of this month

GE: with the language info, there won't be a navigator... should we add language stuff

RB: Meeting Adjourned

<dino> --------------------------------------

<mjs> ACTION: Maciej to remove conformance requirements on non-default views per resolution of ISSUE-61

<trackbot> Created ACTION-177 - Remove conformance requirements on non-default views per resolution of ISSUE-61 [on Maciej Stachowiak - due 2006-05-10].

<mjs> ACTION: Maciej to remove redundant requirements on redundant requirment on UIEvent.view per resolution of ISSUE-63

<trackbot> Created ACTION-178 - Remove redundant requirements on redundant requirment on UIEvent.view per resolution of ISSUE-63 [on Maciej Stachowiak - due 2006-05-10].

<mjs> ACTION: Maciej to add support for Window as an EventTarget and in the DOM event flow (except "load" events!) per resolution of ISSUE-64

<trackbot> Created ACTION-179 - Add support for Window as an EventTarget and in the DOM event flow (except \"load\" events!) per resolution of ISSUE-64 [on Maciej Stachowiak - due 2006-05-10].

<mjs> ACTION: Maciej to add document.parentWindow per resolution of ISSUE-65 [recorded in http://www.w3.org/2006/05/02-webapi-minutes.html#action19]

<trackbot> Created ACTION-180 - Add document.parentWindow per resolution of ISSUE-65 [on Maciej Stachowiak - due 2006-05-10].

<mjs> ACTION: Maciej to specify that documents that are not being presented have a null defaultView

<trackbot> Created ACTION-181 - Specify that documents that are not being presented have a null defaultView [on Maciej Stachowiak - due 2006-05-10].

<mjs> ACTION: Maciej to specify relative URI resolution for the location object for JavaScript only in language bindings per resolution of ISSUE-67

<trackbot> Created ACTION-182 - Specify relative URI resolution for the location object for JavaScript only in language bindings per resolution of ISSUE-67 [on Maciej Stachowiak - due 2006-05-10].

<mjs> ACTION: Maciej to put location string conversion rule in JS language bindings per resolution of ISSUE-68

<trackbot> Created ACTION-183 - Put location string conversion rule in JS language bindings per resolution of ISSUE-68

<bjoern> I suppose you'll win the who-got-most-actions-done contest...

<mjs> ACTION: Maciej to specify optional bool requirement to location.reload per resolution of ISSUE-69

<trackbot> Created ACTION-184 - Specify optional bool requirement to location.reload per resolution of ISSUE-69 [on Maciej Stachowiak - due 2006-05-10].

<mjs> ACTION: Maciej to spec trivial language-independent timers w/ no change for ES per resolution of ISSUE-70

<trackbot> Created ACTION-185 - Spec trivial language-independent timers w/ no change for ES per resolution of ISSUE-70 [on Maciej Stachowiak - due 2006-05-10].

Summary of Action Items

[NEW] ACTION: DS to make a public proposal on the softkey issue
[NEW] ACTION: DS to specify keypress, keyCode, charCode
[NEW] ACTION: DS to talk to MMI/Ink about pressure
[NEW] ACTION: GE to make a proposal for the other X/Y things like clientX/Y
[NEW] ACTION: GE to make a public proposal on the softkey issue
[NEW] ACTION: IH to make a public proposal on the softkey issue
[NEW] ACTION: IH to suggest a security exception
[NEW] ACTION: JS to make a proposal for lock-down of the tree during mutation events
[NEW] ACTION: Maciej to add document.parentWindow per resolution of ISSUE-65
[NEW] ACTION: Maciej to add support for Window as an EventTarget and in the DOM event flow (except "load" events!) per resolution of ISSUE-64
[NEW] ACTION: Maciej to draft fraggle rock event (mouse wheel)
[NEW] ACTION: Maciej to make a proposal to change mutation events such that they are easier to implement
[NEW] ACTION: Maciej to put location string conversion rule in JS language bindings per resolution of ISSUE-68
[NEW] ACTION: Maciej to remove conformance requirements on non-default views per resolution of ISSUE-61
[NEW] ACTION: Maciej to remove redundant requirements on redundant requirment on UIEvent.view per resolution of ISSUE-63
[NEW] ACTION: Maciej to spec trivial language-independent timers w/ no change for ES per resolution of ISSUE-70
[NEW] ACTION: Maciej to specify optional bool requirement to location.reload per resolution of ISSUE-69
[NEW] ACTION: Maciej to specify relative URI resolution for the location object for JavaScript only in language bindings per resolution of ISSUE-67
[NEW] ACTION: Maciej to specify that documents that are not being presented have a null defaultView
[NEW] ACTION: maciej to write up proposal for abstracted key events
[NEW] ACTION: RB to make a public proposal on the softkey issue
[NEW] ACTION: RB to redraft keylongpress based on discussion

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2006/05/03 06:00:24 $