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

Minutes: DOM3 Events Telcon, 23 Sept 2009

From: Doug Schepers <schepers@w3.org>
Date: Wed, 23 Sep 2009 18:43:45 -0400
Message-ID: <4ABAA4A1.4020104@w3.org>
To: "www-dom@w3.org" <www-dom@w3.org>
Hi, Folks-

The minutes for the DOM3 Events telcon of Wednesday, 23 Sept 2009 can be 
found here:

   http://www.w3.org/2009/09/23-webapps-minutes.html

Or as text below:

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

              Web Applications Working Group Teleconference

23 Sep 2009

    [2]Agenda

       [2] http://www.w3.org/mid/4ABA6384.9020108@w3.org

    See also: [3]IRC log

       [3] http://www.w3.org/2009/09/23-webapps-irc

Attendees

    Present
           Shepazu, mauro, chaals, smaug, travis

    Regrets
    Chair
           shepazu

    Scribe
           chaals

Contents

      * [4]Topics
          1. [5]Initialising events
          2. [6]Dropping event namespace init methods
          3. [7]focusin/focusout, mouseenter/mouseleave, and
             detectability
          4. [8]key identifiers and convertKeyIdentifier
          5. [9]feature detection and fallbacks (featurestrings?)
          6. [10]TPAC
          7. [11]Resize event
          8. [12]Meeting time
      * [13]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 23 September 2009

    <scribe> scribe: chaals

Initialising events

    DS: Suggestion is to either deprecate (or drop or shove away from
    the spotlight) event initialisers like initMouseEvent
    ... One idea: between creating and dispatching an event the
    properties would be writeable, to save remembering long unwieldy
    parameter patterns.
    ... Smaug, you didn't like it. Why?

    OP: Changing attributes to read/write feels odd.
    ... but the init methods are awkward, so maybe OK.

    DS: Right. The init* are already awkward. Making them writeable is
    more extensible than adding parameters

    OP: Yes.
    ... We would then need to define default values for unitialised
    properties.

    DS: So we would allow that and define for what? each event?

    OP: Yes, for each event... or maybe each interface.

    CMN: We only need to define non-optionals. And we coul just say "if
    the required attributes aren't met then we just throw away the
    event"

    OP: Type is the only property that must be set. everything else
    should have some reasonable default value.

    DS: Right now we create an event interface, and then initialise an
    event and say what you want.

    <smaug> var e = new Event("scroll");

    DS: strikes me as really awkward. Why not say
    'createEvent("foobar")'

    <smaug> var e = new MouseEvent("click");

    DS: each event type knows what its interface is

    OP: You can create a click event that implements the normal
    interface

    DS: Why is that useful

    OP: It isn't. It is just there

    DS: If your chief objetion was that making attributes writeable was
    odd, but we agree that so is initialisers, I prefer to go with the
    one that doesn't reqire an nitialiser. Init event would still work
    where it is defined, but I would not define it for new events.

    OP: What about creating events?

    DS: I will propose something about creating events by type rather
    than by interface.

    OP: Can you still overwrite type?
    ... you need a way to create a specific interface, or an object that
    implements it, then set a type identified in the spec, because
    people use their own events.
    ... that is why creating mouseevent by saying new mouseEvent(type)
    should work.

    DS: OK, we should look at that further...

Dropping event namespace init methods

    DS: Talked to other team members about this
    ... asked them what general tenor in groups is.
    ... nobody had a problem with dropping them

    OP: OK.

    DS: While they have some hope (a namespace can be just another
    attribute), I am proposing dropping methods devoted to namespaced
    events

    OP: You then need to define how event listeners work with
    namespaces.

    DS: Uploaded a draft that removes most *NS versions of methods. What
    about addEventListenerNS ?
    ... proposing to drop that too.

    OP: So namespace disappears from the spec?

    DS: It is all through the spec. In those places, and in mutation
    events if someone changes the namespace of an attribute you can
    change that.

    OP: There is the NS URI still in there?
    ... if you drop NSlistener the namespace URI in the event doesn't
    mean anything

    DS: So how far do we want to go with this?

    TL: Drop 'em.

    DS: So checking that you think it makes sense to remove all
    namespaces...

    TL: Even if you put them back in, we will not implement them.

    DS: So it makes sense to drop them

    TL: Just saying, if you bring them back, it will take *at least*
    another release to get them in.
    ... can see Xforms complaining...

    DS: Asked, and the team contacts said nobody would seriously
    complain. IT is not clear content uses them, ...

    TL: We shouldn't be tied to the drafts...

    DS: Sure, although we should respect people who were trying to do
    the right thing

    RESOLUTION: Drop namespaced events

focusin/focusout, mouseenter/mouseleave, and detectability

    OP: The change of namespace mutation event is a different beast -
    please don't kill it

    DS: Right.
    ... Moved focus to its own interface. will probably add from and to
    to the interface

    OP: why?
    ... is that what IE has?

    DS: It is. Garrett says detectability of that element might be very
    mportant to content.

    TL: Nobody will use focusin/out, they will use onfocusin/out. So
    there is a possibility that a website tries all events from IE,
    which might break, but it doesn't seem like a big deal.
    ... if youdon't support all the other properties IE has, it will
    still break. SO design it the way you want it to be.

    DS: Garrett suggested we should name the events differently to avoid
    breaking content
    ... e.g. focusenter/leave to match mouse...

    TL: there wa another discussion asking focusin/out to bubble. Do
    they bubble today?

    DS: yes

    OP: the problem is with focus/blur not bubbling

    TL: We need to make a rpincipled decision - are these being added
    for compatibility or some other purpose?

    DS: Doesn't seem like they will be compatible, but they are useful
    for the characteristics they have

    OP: Agree

    DS: So changing the name is not such a problem

    OP: ditto mouseenter/leave

    DS: Don't think they have the same problem

    OP: All event listeners use the same properties, (IE) not DOM
    properties.

    DS: We are really going for functionality, not just compatibility.

    OP: The new functioanlity is useful

    DS: People are arguing against adding new functionality...

    TL: like us
    ... for the toEleement/from, I don't care

    DS: If we don't add them, people can detect if they exist and act
    accordingly.

    TL: A scenario. I want to support old IE and a new browser ith
    focusin/out.
    ... my code has to switch between addeventlistener and attachevent.
    In both cases I can use focusin. so now I register in both browsers,
    the event fires and a listener gets it.
    ... now I have to write code that detects (e.g.) toElement to see if
    this is an IE browser and use it, otherwise I assume that
    relatedTarget is there and use it. Otherwise, if we made the names
    the same, I could just use them.

    OP: there are other properties in IE in any case

    CMN: Travis' example still holds...
    ... if ou are doing the same thing, wy force people to branch -
    leave that for where there are different functionalities

    TL: Garrett has a point...

    DS: it is a little more code to maintain for browsers. But not much.
    Maybe we should take this to the list
    ... think Garrett certainly has a point worth exploring. I won't
    change the spec now, but willing to entertain the notion that we
    should.

    TL: I don't have a strong opinion yet...

    OP: I think the best solution for content authors is to rename the
    events.

    DS: I am fine with that. Would it apply to both focus* and mouse*?

    TL: Maybe both.

    OP: Please post it to the list so we can think about it more with
    more input

    <scribe> ACTION: Doug to post something to the list on focusin/out
    and mouseenter/leave on event names [recorded in
    [14]http://www.w3.org/2009/09/23-webapps-minutes.html#action01]

    <trackbot> Created ACTION-407 - Post something to the list on
    focusin/out and mouseenter/leave on event names [on Doug Schepers -
    due 2009-09-30].

key identifiers and convertKeyIdentifier

    TL: I can see it applying to mouse* - it makes our stories
    consistent

    DS: Anne / Maciej asked why we are doing the strings the way they
    are?
    ... I asked PLH why they were like that and he said he doesn't think
    there was any particular reason. don't know if it means something in
    Java - is it javascript only or universal?

    TL: THink it works like that in C# in a string literal

    DS: Then it is probably like that in Java. Where is this defined -
    per language, or is there some external spec?

    TL: Should check Java and see what they have

    DS: No objection to doing the / - in many cases it makes more sense.
    I still think there will be times when people want to get teh
    unicode value (codepoint), although I am having trouble articulating
    a use case.
    ... if you have a virtual keyboard and want to say what the unicode
    codepoint is. I think there will be cases where someone wants the
    codepoint.

    TL: Can you turn that into an HTML identity?

    <Travis> \u is supported in Java:
    [15]http://java.sun.com/docs/books/tutorial/i18n/text/string.html

      [15] http://java.sun.com/docs/books/tutorial/i18n/text/string.html

    DS: Added a convenience constant to turn things into entities
    ... makes a numeric entity. Wouldn't change something to &amp;, it
    would change it to &2342; (or whatever)

    TL: That's useful

    DS: Not sure if there is a way of doing that now in JS. If you can
    get the codepoint you can make the entity, because that is a string
    operation. But if we do make a helper method, we may as well add
    more of what we thing will be useful functionality.
    ... converting to an entity, extracting codepoint as string, ...
    ... If I have the shift key, it doesn't have a Unicode
    representation. It's named. So if I said charAt for that it will
    give me the same as S.
    ... something running around my head says we don't want to use
    charCodeAt, we want a helper function - either keyname or code point
    or whatever.

    TL: looking at a JS/unicode site. /u is supported natively in JS

    <Travis> [16]http://javascript.about.com/library/blunicode.htm

      [16] http://javascript.about.com/library/blunicode.htm

    DS: I couldn't figure out how to get charCodeAt to gve me the
    unicode codepoint in FF when I tested.
    ... Looks useful (except it doesn't work for me)

    OP: Do we want to support things over the 64k limit?

    DS: Maciej doesn't see the use case for supporting those - they are
    not on keyboards

    OP: Are we sure?

    <smaug>
    [17]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Event
    s.html#glossary-unicode-code-point

      [17] 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#glossary-unicode-code-point

    DS: I don't know, and don't know it will stay that way. Seems like
    an artificial limit and not sure why we should limit people that
    way.

    OP: In the spec now, the limit is 10FFFF

    TL: The HTML5 parsing spe has a hard limit on codepoint when doing
    character conversion.

    <shepazu>
    [18]https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/O
    bjects/String/charCodeAt

      [18] 
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Objects/String/charCodeAt

    <Travis>
    [19]https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Unico
    de

      [19] 
https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Unicode

    DS: I think encapsulating this in a helper function would be useful.
    It is a unicode helper that also knows about named keys. So you
    could use things beyond key events to resolve this stuff into
    entitites, etc.
    ... this is just about making things more user-friendly. I am going
    to resist not putting this in...
    ... let's define helpers that people might find, and then see what
    happens.
    ... One other aspect. We call the attribute KeyIdentifier. I think
    nobody likes that... and I don't want to say "key". At the same time
    once it is propogated I think people will understand.
    ... waht about having "key" as the attribute?

    TL: no conflicts?

    DS: Apparently not...

    TL: So simple...

    OP: What about "key" and "location"

    DS: Let's try it and see what happens

    RESOLUTION: We will use the escape sequence for value for keyname
    ... We will try to describe a helper function for conversion

    TL: The one specced out now?

    DS: Same general idea. Right now we have characer value and unicode
    string. we are dropping unicode string and making character value an
    escape sequence
    ... will note that parsers may only deal with characters up to a
    certain range.

    RESOLUTION: Change keyIdentifier to key and keyLocation to location
    (and see if it breaks anything)

feature detection and fallbacks (featurestrings?)

    DS: I am sympathetic to Garrett's call for feature detection for
    feautures, but not sure how to do it and have seen resistance from
    browers

    OP: Would be great but I ahven't seen a reasonable proposal and
    don't have a good one.

    DS: You could get this by defining feature strings for each event
    (e.g. hasFeature('events#wheel')
    ... would not be backwartds compatible, but could be a basis for
    moving forward

    OP: would not work with greasemonkey scripts or similar

    [scribe missed reasoning]

    DS: True. Nor plugins, unless you build in a way for a script to
    register an event type.

    <smaug> the reason mentioned on the mailing few weeks ago

    DS: but even so, most browsers won't have extensions/plugins/...
    that add event functionality
    ... that have to be sent to the browser.
    ... seems like having it would be better than nothing if browsers
    supporte it moving forward?

    TL: From a binary standpoint, IE has two ways of hooking events. An
    event sync (which we are removing for performance), and a connection
    point interface, used for the control to fire its own events into
    the browser
    ... it is more like a callback system. no event is sent, you use
    addEventListener to register a name you know, and when you throw
    your event we map your name to your callback. Those events neve
    collide with system events.
    ... until we get HTML+JS extensibility model there is no need to
    know what events you support

    DS: even failing for browser extensions of various kinds, the number
    of authors served by saying "does this browser support foo? Or
    should I fall back to older behaviour?"
    ... planning to write a script library for D3E (as far as possible)
    ... so people can code to it no matter what their browser. Detecting
    if a browser claimed to support something would be really useful.

    OP: Could be useful in some cases

    DS: It won't be universally useful - will be false +ve and -ve but I
    will go ahead and put in feature strings for each event.

    CMN: The argument against it is that as you get into a wider range
    of browsers and browser types, the value drops below the cost.

    DS: If we have a specific means to detect stuff, and a browser lies,
    there is a rationale to call them out in public and say stop that.
    ... If you do this by event type, there is a much wider range of
    useful information that comes from the feature string tha if it is
    from an interface.
    ... there will be failures, but there always are

    TL: THe difference is that existing object level detection is
    already fine grained with property checking. Events don't have a
    property in the same way
    ... seems like there is value in having one API that tells you
    something about the UA, and lets you detect features.
    ... browsers have hasFeature, and if you get a useful answer that's
    ok, but if you get a false +/-ve then you do what you are already
    doing going into deeper testing.

    DS: Doesn't help with code paths but helps with building script
    libraries etc.

    TL: Doing this will be useful over time.

    DS: The mistake in SVG was to make the hasFeature too
    coarse-grained, so it was too hard to use it efficiently.
    ... now we want to support it at the attribute-for-an-element level.
    ... it isn't like you need to store a bunch of strings, just know
    that when you implement a new event you expose it to hasFeature.
    They are compositional
    ... so I will put that in, and we will see what happens

    RESOLUTION: We will add per-event-type feature string algorithm, and
    see what happens.

    DS: If something answers hasFeature to blah then it is clear it is
    the IE IE model

TPAC

    CMN: When people register, it woudl be really helpful to say whether
    you are going for widgets or APIs since the WG is split into two
    rooms.

Resize event

    TL: OP, you were thinking about the event not bubbling...

    <shepazu>
    [20]http://www.w3.org/mid/6eeb8bd10906241911l191c6710va55d7ddbd86399
    f7@mail.gmail.com

      [20] 
http://www.w3.org/mid/6eeb8bd10906241911l191c6710va55d7ddbd86399f7@mail.gmail.com

    <shepazu> [[

    <shepazu> Another important thing to remember is that onresize does
    not bubble.

    TL: we were talking about not letting it target element. Events for
    arbitrary elements should not be allowed to bubble... (and for
    window it doesn't make much difference)

    <shepazu> ]]

    TL: or keeping it as is but removing elementTarget

    OP: and add somethig new for elements?

    TL: yeah, in a later spec.

    OP: So when resize fires on IE at document, does it go to document
    or window?

    TL: body, I think...

    OP: What if body element is resized but not the document?

    TL: then I think we fire it.

    OP: thnking of making a similar mess to load event...

    TL: If we need that for existing site compat it would probably be
    the best. I haven't tried it

    DS: Should we say resize does not bubble?

    OP: OK with that

    TL: if we do that we might need to do the load-like magic... maybe

    DS: Maybe I have general text that says some events for legacy
    reasons have different flow and these will be noted in the host
    language

    OP: Currently that is just load

    DS: Might be resize too

    OP: What about just making resize not bubble. What will break?

    DS: OK, fine by me.
    ... I should still allow the odd event flow for load, which can
    defer to HTML5

    RESOLUTION: resize will not bubble

Meeting time

    DS: This time is not so good for Smaug, Chaals. Could we move it a
    couple of hours earlier?

    OP: 3 hours earlier was good.

    TL: that's fine.

    CMN: That's better than 2 hours earlier for me.

    <smaug> "mauro" :)

    <shepazu> heh

    <shepazu> trackbot, stop telcon

    <trackbot> Sorry, shepazu, I don't understand 'trackbot, stop
    telcon'. Please refer to [21]http://www.w3.org/2005/06/tracker/irc
    for help

      [21] http://www.w3.org/2005/06/tracker/irc

    <shepazu> trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: Doug to post something to the list on focusin/out and
    mouseenter/leave on event names [recorded in
    [22]http://www.w3.org/2009/09/23-webapps-minutes.html#action01]
Received on Wednesday, 23 September 2009 22:43:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT