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 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