IRC log of webapps on 2009-09-16

Timestamps are in UTC.

21:05:52 [RRSAgent]
RRSAgent has joined #webapps
21:05:53 [RRSAgent]
logging to
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]
21:06:39 [shepazu]
let's keep this short, then...
21:06:41 [Zakim]
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]
21:09:01 [Travis]
shepazu: All major browser venders said 'no' to this proposal.
21:09:16 [shepazu]
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]
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]
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]
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
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]
22:21:34 [Zakim]
22:21:40 [Zakim]
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 trackbot
22:22:16 [trackbot]
RRSAgent, bye
22:22:16 [RRSAgent]
I see 1 open action item saved in :
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