See also: IRC log
<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.
<shepazu> 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> 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 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].
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> 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>: 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 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 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 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].
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 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!
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at 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, Travis, Anne_van_Kesteren Present: [Microsoft] aemmons Doug Carmelo smaug anne Travis Anne_van_Kesteren Agenda: http://www.w3.org/2008/webapps/wiki/9_Apr_2008 Found Date: 09 Apr 2008 Guessing minutes URL: http://www.w3.org/2008/04/09-webapi-minutes.html People with action items: aemmons andrewe doug travis WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]