W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Minutes: DOM3 Events Telcon, 16 September 2009

From: Doug Schepers <schepers@w3.org>
Date: Wed, 16 Sep 2009 18:26:11 -0400
Message-ID: <4AB16603.9060304@w3.org>
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:


Or as text below:


       [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


           [Microsoft], Shepazu




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


    <scribe> scribeNick: Travis

    <scribe> scribe: Travis

listen/unlisten 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: most recent draft- added explanitory text about key
    ... 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

    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


    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

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

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

    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,
    ... What do you think?

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

    smaug: +1

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

default actions

    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

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

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


    <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

    shepazu: Also talked awhile ago about providing an enumerator of
    event listeners. Seems too complicated for D3E. We could pursue in
    ... 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


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

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

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

    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

    <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

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

    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
Received on Wednesday, 16 September 2009 22:26:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:55 UTC