21:05:52 <RRSAgent> RRSAgent has joined #webapps
21:05:53 <RRSAgent> logging to http://www.w3.org/2009/09/16-webapps-irc
21:05:54 <trackbot> RRSAgent, make logs public
21:05:54 <Zakim> Zakim has joined #webapps
21:05:56 <trackbot> Zakim, this will be WAPP
21:05:56 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
21:05:57 <trackbot> Meeting: Web Applications Working Group Teleconference
21:05:57 <trackbot> Date: 16 September 2009
21:06:09 <smaug> ok, so if we could have less than 2 hours long telcon this time ;)
21:06:15 <smaug> I need to get up early
21:06:17 <Zakim> +Shepazu
21:06:39 <shepazu> let's keep this short, then...
21:06:41 <Zakim> +??P1
21:07:44 <Travis> scribenick Travis
21:08:05 <shepazu> Topic: listen/unlisten 
21:08:14 <Travis> scribeNick: Travis
21:08:24 <Travis> scribe: Travis
21:08:33 <Travis> topic: listen/unlisten events
21:08:49 <Travis> (methods)
21:09:01 <Travis> shepazu: All major browser venders said 'no' to this proposal.
21:09:16 <shepazu> s/events/methods
21:10:01 <Travis> Resolution: remove listen/unlisten from the spec.
21:10:43 <shepazu> Topic: key identifiers 
21:10:51 <Travis> shepazu: Since it's just an alias, it's not really needed. If it added functionality then that would be a different story.
21:11:10 <shepazu> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset
21:11:28 <Travis> shepazu: most recent draft- added explanitory text about key identifiers.
21:11:38 <Travis> ... please review (members of the working group)
21:11:47 <Travis> ... Q: What _is_ a key identifier?
21:12:28 <Travis> ... Finally realized that a key identifier is not a unique id for a key, it's the value of the key at the given moment with contributions from modifiers, etc.
21:12:38 <Travis> ... It's the input key character.
21:12:58 <Travis> ... A key can have multiple key identifiers. Could be unicode name/value or character
21:14:59 <Travis> Travis: Yes, I like the clarity provided in the new draft.
21:15:18 <Travis> shepazu: Yes, need to put a section that says that multiple literal keys may have the same mapping.
21:16:09 <Travis> ... recently added all lowercase key identifiers to the spec. Looking for comments.
21:16:17 <Travis> ... With that, perhaps close to last call?
21:16:35 <Travis> smaug: I need to review the entire spec again. Can you send mail to list to review as well?
21:16:40 <Travis> shepazu: sure.
21:17:15 <Travis> ... might be appropriate to put out a new draft for review. *could* be a last call draft.
21:17:20 <shepazu> topic: namespaced events 
21:18:07 <Travis> shepazu: Marked these as "at risk"
21:18:33 <Travis> ... I'm concerned about the dependencies that others may have
21:19:06 <Travis> ... During discussion with SVG group recently... was talking about namespace events.
21:19:26 <Travis> ... Can see the complexity in namespace event implementations
21:19:48 <Travis> ... Also having the init* methods for NS adds complexity.
21:20:24 <Travis> ... Is it really common to init events?
21:20:33 <Travis> travis: Have heard of use cases for this...
21:20:51 <Travis> shepazu: Script libraries may use them more...
21:22:34 <Travis> ... Cameron suggested an event initializer that could allow event properties to be read/write until the event was dispatched.
21:23:12 <Travis> Travis: A little weird to declare (since the read/write changes dynamically).
21:23:55 <Travis> shepazu: One advantage is that namespaceURI becomes much less overhead (don't need an separate init* method).
21:24:13 <Travis> Travis: would we then drop the init*NS methods?
21:24:47 <Travis> shepazu: Don't know... could drop them, could even drop all the custom initializers. Will see. Waiting on Cameron's proposal to the lsit.
21:25:17 <shepazu> topic: focus 
21:26:05 <Travis> shepazu: Travis asked why you need the relatedTarget...
21:26:46 <Travis> ... It's a pain to track state (in webpage code). Also use cases don't always use both events
21:29:15 <Travis> Travis: I'm not really opposed to the FocusEvent interface proposal.
21:31:21 <Travis> Travis: I think it's a good idea if we need to have new properties.
21:32:10 <Travis> Resolution: Add a new FocusEvent interface to support the focusin/focusout/focus/blur such that they gain a relatedTarget property.
21:32:36 <Travis> shepazu: There might be an issue with adding new properties...
21:32:53 <Travis> smaug: I don't recall any bugs with our own added properties to MouseEvent
21:33:27 <Travis> shepazu: +DOMFocusIn, +DOMFocusOut (to FocusEvent interface)
21:34:04 <Travis> ... relatedTarget will be the node that the event is going to or coming from. Might also be null.
21:34:45 <Travis> ... for blur/focusout : the relatedTarget is the element that they are going to (opposite of focus/focusin)
21:34:59 <Travis> topic: back to key identifiers (briefly)
21:35:10 <Travis> shepazu: Does anyone implement key identifiers?
21:35:14 <Travis> smaug: Don't think so.
21:35:40 <Travis> shepazu: What if you needed the unicode value? Or the character name (not it's value)...?
21:36:25 <Travis> ... Have some ideas for that: expose it on the event itself with the keyIdentifier (like an array?) or a ConvertTo(keyidentier, newFormat).
21:36:59 <Travis> ... What do you think?
21:38:04 <Travis> Travis: I like the convertTo api. Put it in a new spec (DOM L4 events?).
21:38:08 <Travis> smaug:  +1
21:38:20 <Travis> shepazu: Also good to have available when events are not in use.
21:39:19 <shepazu> topic: default actions 
21:39:20 <Travis> ... Do implementations have a huge list of character<->codes<->identifiers?
21:39:34 <shepazu> topic: default actions
21:40:55 <Travis> shepazu: Changed the events table to organize around default actions... it raised some questions.
21:41:53 <smaug> btw, scroll event isn't the default action of mouwewheel I believe
21:42:14 <smaug> scroll event certainly isn't the default action of wheel event
21:43:45 <Travis> ... For events without default actions but are cancellable, does that mean that an implemention has a default action anyway?
21:44:15 <Travis> smaug: No direct correlation between wheel event and scroll event.
21:44:24 <shepazu> topic: on-* attributes as event listeners?
21:44:24 <Travis> shepazu: OK, will update the spec.
21:45:07 <Travis> shepazu: Talked about onfoo attributes as an implicit addEventListener.
21:45:27 <Travis> ... hixie wasn't too keen on the idea initially, but has recently asked about it.
21:45:50 <Travis> ... hixie may have wanted more detail than we had in the spec at the time.
21:46:00 <Travis> ... Two benefits (I think):
21:46:06 <Hixie> onfoo isn't quite implicitly addEventListener(), it's a lot more complicated. HTML5 defines it all in detail though.
21:46:25 <Hixie> basically each onfoo registers an event listener when the element is created
21:46:35 <Hixie> and changing the value of onfoo doesn't affect that
21:46:50 <Hixie> the listener itself then uses the value of onfoo as part of its processing
21:47:17 <Hixie> html5 also defines some hooks so other specs can make use of these definitions easily
21:47:48 <Hixie> a number of specs make use of this, including at least xhr, eventsource, web sockets, web workers, web storage
21:47:48 <Travis> shepazu: Seems like HTML5 has it covered.
21:47:51 <annevk> I think what HTML5 says might not match implementations. removeAttribute("onfoo", ...) should actually work. Hallvord filed a bug on that.
21:48:14 <Hixie> annevk, that's a separate issue from addEventListener
21:48:28 <annevk> true
21:49:22 <Travis> shepazu: I should say something about this in the spec. (need to define if removeEventListener removes these events, or if they are just special).
21:49:33 <Travis> Travis: (Thinks they are special)
21:49:46 <Travis> ... but what order to the fire in relation to the other eventes?
21:50:10 <Hixie> removeEventListener can't remove them because you can't get a handle to the event handler
21:50:13 <Travis> shepazu: Will probably just reference HTML5 on this issue. (For context within the D3E spec.)
21:50:19 <annevk> order should be registration order
21:50:22 <Travis> True.
21:50:41 <Hixie> order is defined in html5, i believe. at least i intended to define it there. file a bug if it's not defined :-)
21:50:45 <Travis> shepazu: This simplifies the D3E spec. Good.
21:51:03 <Hixie> html5 basically hooks all this into the dom3 events model, so dom3 events shouldn't need to say anything special about it
21:51:14 <Hixie> so long as order is defined in general, i just hook into that
21:51:35 <Travis> ... Also talked awhile ago about providing an enumerator of event listeners. Seems too complicated for D3E. We could pursue in D4E...
21:54:08 <Travis> shepazu: Are folks committed to implementing the features of D3E?
21:54:47 <Travis> Travis: Yes. Will want to extend with experiemental stuff (like faster mutation event API, etc.) but should conform to the spec.
21:54:50 <Travis> smaug: Yes.
21:54:54 <shepazu> Topic: mouse x/y coordinates 
21:55:54 <annevk> oh yeah, I define most of those in http://www.w3.org/TR/cssom-view/#extensions-to-the-mouseevent-interface
21:56:07 <annevk> it would be nice if we figure out a way which spec defines what
21:56:52 <Travis> I don't mind them being in CSS-OM Views. (Planning to graft them in.)
21:57:06 <Travis> (that is...privately)
21:57:25 <Travis> shepazu: Two things in SVG that prevent mouse-location based events:
21:58:07 <Travis> ... 1) transformation - warps the coordinate space (expands/distorts/shifts). Nice for transforming element appearance, but bad for hit-detection, bounding boxes, reverse transformations...
21:58:26 <Travis> ... script libraries do this, but they're implicitly slow.
21:59:04 <Travis> ... 2) view box - grows or shrinks the rendered content (sets a scale--also changes the coordinate space).
21:59:16 <annevk> at some point Apple told me they'd come up with a proposal for a getClientRects() that's transform aware, but it hasn't happened yet
21:59:29 <Travis> ... SVG needs to add some math functions that specifiy how to get the absolute x/y within the current viewport.
21:59:47 <Travis> ... CSS transformations will also need this...
22:00:00 <Travis> .... Thought it would be nice to put it into D3E.
22:00:12 <Travis> Travis: Why this spec?
22:00:25 <Travis> shepazu: Because it has to do with the x/y of various events.
22:02:33 <Travis> ... SVG has backcompat issues with current client*/screen* APIs (can't repurpose to include transformations).
22:03:21 <Travis> ... basically a viewX, viewY to unravel the transformation automagically.
22:03:49 <Travis> ... could put it in the SVG working group, but would not prefer to because it applies to CSS transforms too.
22:04:12 <Travis> ... I'd like to make a proposal to the list about this.
22:04:37 <Travis> Travis: Will also want to run this by some IE folks.
22:06:21 <Travis> shepazu: For non transformed elements, this is just clientX/Y...
22:07:30 <Travis> Travis: Web authors may want their coordinate in pageX/Y, clientX/Y, pageX/Y, etc. May want a function that does the transformation instead.
22:08:09 <Travis> smaug: And a function also prevents us from having to add another parameter to the init* methods.
22:08:44 <jrossi> jrossi has joined #webapps
22:10:41 <jrossi> jrossi has joined #webapps
22:12:43 <jrossi> Hello from Atlanta.....telecon still going on or did I miss it?
22:13:29 <shepazu> jrossi: just finishing up
22:14:34 <jrossi> ah ok
22:14:58 <Travis> Action: Travis to send proposal on element-level reize events to be put on the wishlist.
22:14:58 <trackbot> Created ACTION-406 - Send proposal on element-level reize events to be put on the wishlist. [on Travis Leithead - due 2009-09-23].
22:15:42 <Travis> smaug: Why did some events become UIEvents?
22:16:09 <Travis> shepazu: (also wondering why)
22:16:17 <Travis> ... will look into this.
22:19:38 <Travis> shepazu: back to resize event...
22:19:56 <Travis> smaug: resize event only fires on Window (never on Iframe)
22:21:31 <Zakim> -??P1
22:21:34 <Zakim> -[Microsoft]
22:21:40 <Zakim> -Shepazu
22:21:41 <Zakim> IA_WebApps(DOM3)5:00PM has ended
22:21:43 <Zakim> Attendees were [Microsoft], Shepazu
22:22:14 <shepazu> trackbot, end telcon
22:22:14 <trackbot> Zakim, list attendees
22:22:14 <Zakim> sorry, trackbot, I don't know what conference this is
22:22:15 <trackbot> RRSAgent, please draft minutes
22:22:15 <RRSAgent> I have made the request to generate http://www.w3.org/2009/09/16-webapps-minutes.html trackbot
22:22:16 <trackbot> RRSAgent, bye
22:22:16 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2009/09/16-webapps-actions.rdf :
22:22:16 <RRSAgent> ACTION: Travis to send proposal on element-level reize events to be put on the wishlist. [1]
22:22:16 <RRSAgent>   recorded in http://www.w3.org/2009/09/16-webapps-irc#T22-14-58