- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 09 Apr 2008 15:57:15 -0400
- 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:
http://www.w3.org/2008/04/09-webapi-minutes.html
Or as text, below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Web API WG Teleconference
09 Apr 2008
[2]Agenda
[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
Attendees
Present
[Microsoft], aemmons, Doug, Carmelo, smaug, anne, Travis,
Anne_van_Kesteren
Regrets
Chair
Doug
Scribe
Andrew
Contents
* [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
<shepazu>
[9]http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0066.ht
ml
[9]
http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0066.html
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
getEventListeners
<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
dispatching
... 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
<anne>
[10]http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-Event
[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
tradition.
DS: Most implementations have robust live lists
... have them anyway
<scribe> ACTION: Travis to send revised model to the mailing list
[recorded in
[11]http://www.w3.org/2008/04/09-webapi-minutes.html#action01]
<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>:
[13]http://blog.nihilogic.dk/2008/04/super-mario-in-14kb-javascript.
html
[13]
http://blog.nihilogic.dk/2008/04/super-mario-in-14kb-javascript.html
<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',
funcReWireKeys);
<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
keys
... 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
insightful)
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
meaning
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
[14]http://www.w3.org/2008/04/09-webapi-minutes.html#action02]
<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
[15]http://www.w3.org/2008/04/09-webapi-minutes.html#action03]
<trackbot> Sorry, couldn't find user - Andrewe
<scribe> ACTION: AEmmons to add keyboard use cases into the spec
[recorded in
[16]http://www.w3.org/2008/04/09-webapi-minutes.html#action04]
<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
keyIdentifiers?
... 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
[17]http://www.w3.org/2008/04/09-webapi-minutes.html#action05]
<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
[18]http://www.w3.org/2008/04/09-webapi-minutes.html#action04]
[NEW] ACTION: Andrewe to add keyboard use cases into the spec
[recorded in
[19]http://www.w3.org/2008/04/09-webapi-minutes.html#action03]
[NEW] ACTION: Doug to place keyboard use cases into the wiki
[recorded in
[20]http://www.w3.org/2008/04/09-webapi-minutes.html#action02]
[NEW] ACTION: Doug to start keyIdentifiers chart on the wiki for
various charCode and keyCode values and browsers [recorded in
[21]http://www.w3.org/2008/04/09-webapi-minutes.html#action05]
[NEW] ACTION: Travis to send revised model to the mailing list
[recorded in
[22]http://www.w3.org/2008/04/09-webapi-minutes.html#action01]
[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
/scribe/
[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
steren
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
tml
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