<chaals> scribenick: chaals
<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)
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
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
RB: In CDF?
<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)
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.
<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, ...)
<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
mousehweeln
fragglewheel
<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
<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
grr
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
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].
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?
<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
<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 ...
<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].
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
break!
<darobin> scribenick: schepers
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
<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]
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
Resolution: ISSUE-60 deferred
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
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.
Resolution: yes, add parent window
Resolution: yes, but it's complex
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
<mjs> RESOLUTION: string conversion rule is only for ECMAScript, defined in language bindings
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
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
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].