Web Applications Working Group Teleconference -- 16 Sep 2009

<trackbot> Date: 16 September 2009

<smaug> ok, so if we could have less than 2 hours long telcon this time ;)

<smaug> I need to get up early

<shepazu> let's keep this short, then...

scribenick Travis

listen/unlisten

<scribe> scribeNick: Travis

<scribe> scribe: Travis

listen/unlisten methods

(methods)

shepazu: All major browser venders said 'no' to this proposal.

Resolution: remove listen/unlisten from the spec.

key identifiers

shepazu: Since it's just an alias, it's not really needed. If it added functionality then that would be a different story.

<shepazu> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset

shepazu: most recent draft- added explanitory text about key identifiers.
... please review (members of the working group)
... Q: What _is_ a key identifier?
... 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.
... It's the input key character.
... A key can have multiple key identifiers. Could be unicode name/value or character

Travis: Yes, I like the clarity provided in the new draft.

shepazu: Yes, need to put a section that says that multiple literal keys may have the same mapping.
... recently added all lowercase key identifiers to the spec. Looking for comments.
... With that, perhaps close to last call?

smaug: I need to review the entire spec again. Can you send mail to list to review as well?

shepazu: sure.
... might be appropriate to put out a new draft for review. *could* be a last call draft.

namespaced events

shepazu: Marked these as "at risk"
... I'm concerned about the dependencies that others may have
... During discussion with SVG group recently... was talking about namespace events.
... Can see the complexity in namespace event implementations
... Also having the init* methods for NS adds complexity.
... Is it really common to init events?

travis: Have heard of use cases for this...

shepazu: Script libraries may use them more...
... Cameron suggested an event initializer that could allow event properties to be read/write until the event was dispatched.

Travis: A little weird to declare (since the read/write changes dynamically).

shepazu: One advantage is that namespaceURI becomes much less overhead (don't need an separate init* method).

Travis: would we then drop the init*NS methods?

shepazu: Don't know... could drop them, could even drop all the custom initializers. Will see. Waiting on Cameron's proposal to the lsit.

focus

shepazu: Travis asked why you need the relatedTarget...
... It's a pain to track state (in webpage code). Also use cases don't always use both events

Travis: I'm not really opposed to the FocusEvent interface proposal.
... I think it's a good idea if we need to have new properties.

Resolution: Add a new FocusEvent interface to support the focusin/focusout/focus/blur such that they gain a relatedTarget property.

shepazu: There might be an issue with adding new properties...

smaug: I don't recall any bugs with our own added properties to MouseEvent

shepazu: +DOMFocusIn, +DOMFocusOut (to FocusEvent interface)
... relatedTarget will be the node that the event is going to or coming from. Might also be null.
... for blur/focusout : the relatedTarget is the element that they are going to (opposite of focus/focusin)

back to key identifiers (briefly)

shepazu: Does anyone implement key identifiers?

smaug: Don't think so.

shepazu: What if you needed the unicode value? Or the character name (not it's value)...?
... Have some ideas for that: expose it on the event itself with the keyIdentifier (like an array?) or a ConvertTo(keyidentier, newFormat).
... What do you think?

Travis: I like the convertTo api. Put it in a new spec (DOM L4 events?).

smaug: +1

shepazu: Also good to have available when events are not in use.

default actions

shepazu: Do implementations have a huge list of character<->codes<->identifiers?
... Changed the events table to organize around default actions... it raised some questions.

<smaug> btw, scroll event isn't the default action of mouwewheel I believe

<smaug> scroll event certainly isn't the default action of wheel event

shepazu: For events without default actions but are cancellable, does that mean that an implemention has a default action anyway?

smaug: No direct correlation between wheel event and scroll event.

on-* attributes as event listeners?

shepazu: OK, will update the spec.
... Talked about onfoo attributes as an implicit addEventListener.
... hixie wasn't too keen on the idea initially, but has recently asked about it.
... hixie may have wanted more detail than we had in the spec at the time.
... Two benefits (I think):

<Hixie> onfoo isn't quite implicitly addEventListener(), it's a lot more complicated. HTML5 defines it all in detail though.

<Hixie> basically each onfoo registers an event listener when the element is created

<Hixie> and changing the value of onfoo doesn't affect that

<Hixie> the listener itself then uses the value of onfoo as part of its processing

<Hixie> html5 also defines some hooks so other specs can make use of these definitions easily

<Hixie> a number of specs make use of this, including at least xhr, eventsource, web sockets, web workers, web storage

shepazu: Seems like HTML5 has it covered.

<annevk> I think what HTML5 says might not match implementations. removeAttribute("onfoo", ...) should actually work. Hallvord filed a bug on that.

<Hixie> annevk, that's a separate issue from addEventListener

<annevk> true

shepazu: I should say something about this in the spec. (need to define if removeEventListener removes these events, or if they are just special).

Travis: (Thinks they are special)
... but what order to the fire in relation to the other eventes?

<Hixie> removeEventListener can't remove them because you can't get a handle to the event handler

shepazu: Will probably just reference HTML5 on this issue. (For context within the D3E spec.)

<annevk> order should be registration order

True.

<Hixie> order is defined in html5, i believe. at least i intended to define it there. file a bug if it's not defined :-)

shepazu: This simplifies the D3E spec. Good.

<Hixie> html5 basically hooks all this into the dom3 events model, so dom3 events shouldn't need to say anything special about it

<Hixie> so long as order is defined in general, i just hook into that

shepazu: Also talked awhile ago about providing an enumerator of event listeners. Seems too complicated for D3E. We could pursue in D4E...
... Are folks committed to implementing the features of D3E?

Travis: Yes. Will want to extend with experiemental stuff (like faster mutation event API, etc.) but should conform to the spec.

smaug: Yes.

mouse x/y coordinates

<annevk> oh yeah, I define most of those in http://www.w3.org/TR/cssom-view/#extensions-to-the-mouseevent-interface

<annevk> it would be nice if we figure out a way which spec defines what

I don't mind them being in CSS-OM Views. (Planning to graft them in.)

(that is...privately)

shepazu: Two things in SVG that prevent mouse-location based events:
... 1) transformation - warps the coordinate space (expands/distorts/shifts). Nice for transforming element appearance, but bad for hit-detection, bounding boxes, reverse transformations...
... script libraries do this, but they're implicitly slow.
... 2) view box - grows or shrinks the rendered content (sets a scale--also changes the coordinate space).

<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

shepazu: SVG needs to add some math functions that specifiy how to get the absolute x/y within the current viewport.
... CSS transformations will also need this...
... Thought it would be nice to put it into D3E.

Travis: Why this spec?

shepazu: Because it has to do with the x/y of various events.
... SVG has backcompat issues with current client*/screen* APIs (can't repurpose to include transformations).
... basically a viewX, viewY to unravel the transformation automagically.
... could put it in the SVG working group, but would not prefer to because it applies to CSS transforms too.
... I'd like to make a proposal to the list about this.

Travis: Will also want to run this by some IE folks.

shepazu: For non transformed elements, this is just clientX/Y...

Travis: Web authors may want their coordinate in pageX/Y, clientX/Y, pageX/Y, etc. May want a function that does the transformation instead.

smaug: And a function also prevents us from having to add another parameter to the init* methods.

<jrossi> Hello from Atlanta.....telecon still going on or did I miss it?

<shepazu> jrossi: just finishing up

<jrossi> ah ok

<scribe> ACTION: Travis to send proposal on element-level reize events to be put on the wishlist. [recorded in http://www.w3.org/2009/09/16-webapps-minutes.html#action01]

<trackbot> Created ACTION-406 - Send proposal on element-level reize events to be put on the wishlist. [on Travis Leithead - due 2009-09-23].

smaug: Why did some events become UIEvents?

shepazu: (also wondering why)
... will look into this.
... back to resize event...

smaug: resize event only fires on Window (never on Iframe)

<shepazu> trackbot, end telcon

- DRAFT -

Web Applications Working Group Teleconference

16 Sep 2009

Attendees

Contents