- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 16 Sep 2009 18:26:11 -0400
- To: "www-dom@w3.org" <www-dom@w3.org>
Hi, DOM3 Events Folks-
The minutes for the DOM3 Events telcon of Wednesday, 16 September 2009
can be found here:
http://www.w3.org/2009/09/16-webapps-minutes.html
Or as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Web Applications Working Group Teleconference
16 Sep 2009
See also: [2]IRC log
[2] http://www.w3.org/2009/09/16-webapps-irc
Attendees
Present
[Microsoft], Shepazu
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Travis
Contents
* [3]Topics
1. [4]listen/unlisten
2. [5]listen/unlisten methods
3. [6]key identifiers
4. [7]namespaced events
5. [8]focus
6. [9]back to key identifiers (briefly)
7. [10]default actions
8. [11]on-* attributes as event listeners?
9. [12]mouse x/y coordinates
* [13]Summary of Action Items
_________________________________________________________
<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>
[14]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Event
s.html#keyset
[14]
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
[15]http://www.w3.org/TR/cssom-view/#extensions-to-the-mouseevent-in
terface
[15]
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
[16]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
Summary of Action Items
[NEW] ACTION: Travis to send proposal on element-level reize events
to be put on the wishlist. [recorded in
[17]http://www.w3.org/2009/09/16-webapps-minutes.html#action01]
Received on Wednesday, 16 September 2009 22:26:21 UTC