See also: IRC log
<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...
<scribe> scribeNick: Travis
<scribe> scribe: Travis
shepazu: All major browser venders said 'no' to this proposal.
Resolution: remove listen/unlisten from the spec.
shepazu: Since it's just an alias, it's not really needed. If it added functionality then that would be a different story.
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
... 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?
... might be appropriate to put out a new draft for review. *could* be a last call draft.
shepazu: Marked these as "at
... 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
... 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.
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
+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)
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?).
shepazu: Also good to have available when events are not in use.
shepazu: Do implementations have
a huge list of
... 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.
shepazu: OK, will update the
... 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
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
... 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
<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.
<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.)
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
... will look into this.
... back to resize event...
smaug: resize event only fires on Window (never on Iframe)
<shepazu> trackbot, end telcon
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/events/methods/ Found ScribeNick: Travis Found Scribe: Travis Inferring ScribeNick: Travis Default Present: [Microsoft], Shepazu Present: [Microsoft] Shepazu WARNING: Fewer than 3 people found for Present list! WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 16 Sep 2009 Guessing minutes URL: http://www.w3.org/2009/09/16-webapps-minutes.html People with action items: travis[End of scribe.perl diagnostic output]