W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

Minutes, DOM3 Events Telcon, 09 April 2008

From: Doug Schepers <schepers@w3.org>
Date: Wed, 09 Apr 2008 15:57:15 -0400
Message-ID: <47FD1F9B.2050505@w3.org>
To: Web API public <public-webapi@w3.org>

Hi, WebAPI fans-

The minutes for the 02 April 2008 DOM3 Events telcon can be found here:


Or as text, below:


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

                                - DRAFT -

                        Web API WG Teleconference
                               09 Apr 2008


       [2] http://www.w3.org/2008/webapps/wiki/9_Apr_2008

    See also: [3]IRC log

       [3] http://www.w3.org/2008/04/09-webapi-irc


           [Microsoft], aemmons, Doug, Carmelo, smaug, anne, Travis,




      * [4]Topics
          1. [5]Event Iterators
          2. [6]Keyboard events and KeyIdentifiers
          3. [7]keyCode and charCode
      * [8]Summary of Action Items

    <trackbot> Date: 09 April 2008

    <Travis> Script <not it>

    <Travis> ahem <scribe>

    ech is better

    <Travis> IP phone should be coming next week :)

    <Travis> (w/headset :))

    <scribe> Scribe: Andrew

    <scribe> ScribeNick: aemmons

    <Travis> oh well.

Event Iterators



    AvK: Previously dropped methods that allowed iterations

    DS: When was it dropped?

    AvK: About a year

    DS: Do you know why?

    AvK: Lack of use cases

    <Travis> I wouldn't have proposed it, except MS had some customers
    asking for such a thing. (Framework guys mostly.)

    <anne> > hasEventListenerNS

    <anne> was the thing

    DS: Seems OK with me - one flaw regarding the null paramater
    ... Lots of events will be in the null namespace
    ... With your scheme you will also get them in 'foo' namespace

    TL: I agree

    DS: getElementsByTagNameNS with a wildcard
    ... Other than that looks fine

    <Travis> Use "*" instead of null to filter by 'all'

    DS: I am surprised by the lack of use cases

    AvK: May be other reasons

    <Travis> <Travis hides behind the mute button>

    OP: I do not like using null as a value for the second paramater of

    <Travis> Hmm. Can't provide null or "*" for boolean type.

    OP: Strange to have true, false, null

    <Travis> Good point.

    <Travis> Alternate proposal?

    DS: Would be true, false, *
    ... But can't have * as boolean

    <Travis> Perhaps: DOMString captureFilter {"capture", "bubble", "*"}

    DS: In practice, who uses the useCapture aspect of events

    TL: All event listeners on the capture phase would be returned

    AvK: Most events listed in capture phase

    DS: Why want to get ONLY those that are capture
    ... Seems to indicat ein Dom3Ev that there is a target phase
    ... Was this resolved to be added by the group?

    TL: It is when the event is on the element when it is firing
    ... Re-wored diagram intenrally, shows phase at each stage

    DS: We do not explicitly say there is a target phase

    TL: If you did that you could use alternate type of event
    ... Useful paridigm later on

    DS: Does make sense having filter

    <Travis> Hmm. DOMString usePhaseFilter {"capture", "target",
    "bubble", "*"}

    AvK: Contants make more sense

    <Travis> Number instead (they're alredy defined. Good one Anne.

    AE; Good idea

    DS: Yes

    AvK: Already have constants

    <Travis> 0=Capture 1=Target 2=bubble... what value for 'all' (-1)?

    <Travis> +1 to all.

    AvK; on eventPhase


      [10] http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-Event

    DS: Let's have it as a constant

    AE: Should be renamed from useCaptureFilter to something else,
    eventPhaseFilter for exmaple

    TL: What about wildcard for all?

    AvK: We could have another value for all

    <Travis> Just going with tradition :)

    AvK: should be one method - no need for a non NS method

    <Travis> Ah feature creep.

    <anne> :)

    TL: Static or live list - opinion?

    DS: A lot of debate about that

    AvK: I'd say live

    <Travis> getComputedStyle is a live object--it follows in that

    DS: Most implementations have robust live lists
    ... have them anyway

    <scribe> ACTION: Travis to send revised model to the mailing list
    [recorded in

    <trackbot> Created ACTION-271 - Send revised model to the mailing
    list [on Travis Leithead - due 2008-04-16].

Keyboard events and KeyIdentifiers

    DS: Do people think we're making progress on this topic

    TL: Waiting for updated list of keyIdentifiers from Doug

    DS: Certainly needs to be done, don't know if it's blocking

    <shepazu> [12]http://www.w3.org/2006/webapi/track/actions/270

      [12] http://www.w3.org/2006/webapi/track/actions/270

    DS: Do we have a way forward with this issue?
    ... Keyboard events not specified enough
    ... keyIdentifiers may be specified enough

    <Travis> No problem with keyidentifiers

    AE: No problem with keyIndetifiers

    AvK: With the model?

    <anne> I'm ok with the "model"

    DS: Have to assume the model is a solved problem

    <Carmelo> sounds reasonable

    DS: Still some question - if a flowchart of key flow is of value

    OP: Has some value but can be difficult to define
    ... Especially when there is IME

    DS: A qualifier - at any point you may be knocked out of the keyflow

    OP: If we want to define a keyflow we should define a normal keyflow
    for IME
    ... Currently all browsers work differently

    <Travis> Agree.

    DS: How is IE's IME functionality?

    TL: Have yet to close that action

    OP: I was testing, IE dispatches keyDown and keyUps for input
    ... Safari does the same, but also input and textInput events

    <anne> lol

    OP: Was quite strange

    <anne> phone died

    OP: Opera dispatches only one input event per key

    DS: Is it useful to deinfe what IME does?
    ... Should we just say, when IME mode is entered, you are unlikely
    to get any other key events
    ... Likely to get a textInput event at the end of a sequence

    <Travis> In terms of web developer use, I don't know why a web
    developer would care what the IME is doing.

    DS: What are you doing when you want key events in web applications

    <Travis> Use case: simulate a keyboard on a webpage.

    DS: May be useful to have use cases

    AvK: Games

    DS: We will be unable to define location on a keyboard
    ... Anyone making a game, wise to have user define key makpping

    <anne> Super Mario <canvas>:


    <Travis> Through prototyping, scripts can re-route all key values w/
    getters and setters.

    TL: When we do JavaScript language binding, prototype s created for
    the spec
    ... Override all properties to do what you need
    ... One way you could do it in a game

    <Travis> Example:

    <Travis> MouseEvent.prototype.__defineGetter__('keyIdentifier',

    <Travis> :)

    <Travis> Just a way script can alter this stuff.

    <Carmelo> Doug: I will have to leave about 3:30. Will not interrupt
    the call.

    <smaug> UTC time please :)

    <Travis> But for IME, that allows extended key 'values' to be input.

    DS: Anywhere you want to map location of key to functionality,
    rather than value

    <Travis> access keys.

    AvK: Scripts care about actual value - keyboard shortcuts

    <Travis> (Accessibility uses)

    DS: Hotkeys
    ... A little broken, commands used with browser not accessable to
    script authors. Will be overrideen
    ... There was an interesting proposal for allowing script authors to
    have hotkeys
    ... control-shift-?? is a way to access hotkeys


    <smaug> :)

    DS: Web app, want to hit control-S, same as they are used to with
    desktop app

    TL: Browser as application vs web page as an application

    <smaug> Does anyone have a link to that proposal?

    DS: May be useful to specify how browsers should deal with hotkeys
    ... Part of a dedicated specification - rather a different topic

    <chaals> [/me notes that the use cases boil down to something like
    "make the interface match what people expect", "make the keys used
    be a comfortable layout (especially important in games)" and "ensure
    that the keys are actually available and not overriding some
    important functionality the user had" ...]

    <Travis> Also, the drag/drop spec overlaps with this stuff.

    DS: Another use case is grab actual text values
    ... Does not care about location, just the end value

    <chaals> [...oh, and home-made IMEs]

    <Travis> Offhand, if I were designing this from scratch, for key
    events, I would only fire a keypress (perhaps also longkeypress)
    with the keyIdentifier. That would make the eventing system much
    simpler and allow web authors to write their own handling for key
    modifiers, etc.

    <Travis> For IME, keypress would happen after the IME process.

    <Travis> keyIdentifiers already tell you Shift, etc.

    AvK: Key event order - pick one that is logical or make a new one
    since all browsers are different

    TL: If we can all agree, might hold some weight

    DS: This is what we're trying to do for the most part
    ... We've resolved to do this

    <Travis> Yep, that action is on me for IE...

    DS: Discussing if it is useful to have a flowchart to describe it

    <Travis> There's definately a component to the OS of which the
    browser is dependent.

    DS: Each browser on each platform does not work consistently for all
    ... Will have many exceptions, may not be possible to model fully

    AvK: It is implemented, should be possible to model

    <Travis> The ALT key.

    DS: We did talk about having an appendix to discuss know variations
    on behavior
    ... Safari is going to be reporting back with their behavior
    ... And OP, you said you will send a report as well?
    ... I am perfectly happy to find one behavior that works well and
    specify that

    <Travis> (and one that has been implemented cross-OS would be

    DS: Do not think we'll find one
    ... Regarding the offhand comment above, I can think of multi-modal
    situations where it is useful
    ... If I press A key and P key at the same time, may have different

    TL: You could write it in script but have no way to know if a key
    was released

    DS: perhaps key state information with each event would be useful in
    this scenario
    ... Not compatible with DOM 2 events, but interesting

    <Travis> Agree--put keyboard use cases in the spec.

    <scribe> ACTION: Doug to place keyboard use cases into the wiki
    [recorded in

    <trackbot> Created ACTION-272 - Place keyboard use cases into the
    wiki [on Doug Schepers - due 2008-04-16].

    <Travis> anne distracts the call via SuperMario.

    <scribe> ACTION: Andrewe to add keyboard use cases into the spec
    [recorded in

    <trackbot> Sorry, couldn't find user - Andrewe

    <scribe> ACTION: AEmmons to add keyboard use cases into the spec
    [recorded in

    <trackbot> Created ACTION-273 - Add keyboard use cases into the spec
    [on Andrew Emmons - due 2008-04-16].

keyCode and charCode

    DS: OP, how differnt is keyCode and charCode in Moz vs IE?

    OP: IE has only keyCode I think
    ... Mozilla uses charCode only for keyPress
    ... I think Safari uses a mixture of both
    ... Opera reports very different key codes, at least on windows

    DS: Is MS intending to implement keyCode and charCode?

    TL: I think keyIndenifiers is the superset
    ... Move from charCode and keyCode in the long run
    ... Would just assume not do it

    AE: I agree

    DS: Is it useful to define keyCode and charCode in terms of
    ... Chart of keyIndeitifers, keyCode and charCode that are normally
    associated with it

    TL: Sounds great
    ... Call out differences between browsers

    OP: Should be ok, non-normative is better

    <scribe> ACTION: Doug to start keyIdentifiers chart on the wiki for
    various charCode and keyCode values and browsers [recorded in

    <trackbot> Created ACTION-274 - Start keyIdentifiers chart on the
    wiki for various charCode and keyCode values and browsers [on Doug
    Schepers - due 2008-04-16].

    DS: Any other issues with Dom3 Ev we need to solve?

    TL: I would like a return value for add/remove event listener

    OP: Why?
    ... Not backward compatibile also

    <Travis> Thanks all for the feedback!

Summary of Action Items

    [NEW] ACTION: AEmmons to add keyboard use cases into the spec
    [recorded in
    [NEW] ACTION: Andrewe to add keyboard use cases into the spec
    [recorded in
    [NEW] ACTION: Doug to place keyboard use cases into the wiki
    [recorded in
    [NEW] ACTION: Doug to start keyIdentifiers chart on the wiki for
    various charCode and keyCode values and browsers [recorded in
    [NEW] ACTION: Travis to send revised model to the mailing list
    [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [23]scribe.perl version 1.133
     ([24]CVS log)
     $Date: 2008/04/09 19:54:06 $

      [23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [24] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51
Check for newer version at [25]http://dev.w3.org/cvsweb/~checkout~/2002

      [25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/-shit/-shift/
Found Scribe: Andrew
Found ScribeNick: aemmons
Default Present: [Microsoft], aemmons, Doug, Carmelo, smaug, anne, Trav
is, Anne_van_Kesteren
Present: [Microsoft] aemmons Doug Carmelo smaug anne Travis Anne_van_Ke
Agenda: [26]http://www.w3.org/2008/webapps/wiki/9_Apr_2008
Found Date: 09 Apr 2008
Guessing minutes URL: [27]http://www.w3.org/2008/04/09-webapi-minutes.h
People with action items: aemmons andrewe doug travis

      [26] http://www.w3.org/2008/webapps/wiki/9_Apr_2008
      [27] http://www.w3.org/2008/04/09-webapi-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

    End of [28]scribe.perl diagnostic output]

      [28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Wednesday, 9 April 2008 19:57:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:10:00 UTC