Re: Re: Event.key complaints?
On Mon, Dec 3, 2012 at 9:48 AM, Travis Leithead < travis.leith...@microsoft.com> wrote: > >> When were you thinking of kicking off the DOM4 Events process? > > ** ** > > I'd like to have a draft up this week. We may also ask for a FPWD if we're > ready by the 10th. > > ** ** > > I want to have D4E rolling so that stuff we chose to punt from D3E has a > landing pad. > +1 This will make things a lot smoother for D3E I think and allows us to avoid stalling all DOM Event spec work while we try to finalize D3E. > > > *From:* gary...@google.com [mailto:gary...@google.com] *On Behalf Of *Gary > Kacmarcik (?) > *Sent:* Friday, November 30, 2012 6:09 PM > *To:* Travis Leithead > *Cc:* Hallvord Reiar Michaelsen Steen; public-webapps@w3.org > > *Subject:* Re: Re: Event.key complaints? > > ** ** > > On Fri, Nov 30, 2012 at 4:29 PM, Travis Leithead < > travis.leith...@microsoft.com> wrote: > > Awesome stuff Gary. > > > > (And I like that we won't need to change the behavior of key or char in > your proposal—that part made me really nervous, since IE has shipped this > stuff since 9, and I know our new Win8 app model is using it.) > > > > I'm planning in the short term to start a new DOM4 Events spec, which will > be the successor to DOM3 Events. I brought this up at TPAC and there were > no objections. Gary, I'd love you collaboration on specifying your new > "code" property in that spec. > > ** ** > > Sounds good to me. I still have some comments to make on the DOM3 Events > spec, but I'll still send them out knowing that some of them will need to > be punted to DOM4. > > ** ** > > When were you thinking of kicking off the DOM4 Events process? > > ** ** > > -Gary > > ** ** >
RE: Re: Event.key complaints?
>> When were you thinking of kicking off the DOM4 Events process? I'd like to have a draft up this week. We may also ask for a FPWD if we're ready by the 10th. I want to have D4E rolling so that stuff we chose to punt from D3E has a landing pad. From: gary...@google.com [mailto:gary...@google.com] On Behalf Of Gary Kacmarcik (?) Sent: Friday, November 30, 2012 6:09 PM To: Travis Leithead Cc: Hallvord Reiar Michaelsen Steen; public-webapps@w3.org Subject: Re: Re: Event.key complaints? On Fri, Nov 30, 2012 at 4:29 PM, Travis Leithead mailto:travis.leith...@microsoft.com>> wrote: Awesome stuff Gary. (And I like that we won't need to change the behavior of key or char in your proposal—that part made me really nervous, since IE has shipped this stuff since 9, and I know our new Win8 app model is using it.) I'm planning in the short term to start a new DOM4 Events spec, which will be the successor to DOM3 Events. I brought this up at TPAC and there were no objections. Gary, I'd love you collaboration on specifying your new "code" property in that spec. Sounds good to me. I still have some comments to make on the DOM3 Events spec, but I'll still send them out knowing that some of them will need to be punted to DOM4. When were you thinking of kicking off the DOM4 Events process? -Gary
Re: Re: Event.key complaints?
On Fri, Nov 30, 2012 at 4:29 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > Awesome stuff Gary. > > ** ** > > (And I like that we won't need to change the behavior of key or char in > your proposal—that part made me really nervous, since IE has shipped this > stuff since 9, and I know our new Win8 app model is using it.) > > ** ** > > I'm planning in the short term to start a new DOM4 Events spec, which will > be the successor to DOM3 Events. I brought this up at TPAC and there were > no objections. Gary, I'd love you collaboration on specifying your new > "code" property in that spec. > Sounds good to me. I still have some comments to make on the DOM3 Events spec, but I'll still send them out knowing that some of them will need to be punted to DOM4. When were you thinking of kicking off the DOM4 Events process? -Gary
RE: Re: Event.key complaints?
Awesome stuff Gary.
(And I like that we won't need to change the behavior of key or char in your
proposal—that part made me really nervous, since IE has shipped this stuff
since 9, and I know our new Win8 app model is using it.)
I'm planning in the short term to start a new DOM4 Events spec, which will be
the successor to DOM3 Events. I brought this up at TPAC and there were no
objections. Gary, I'd love you collaboration on specifying your new "code"
property in that spec.
-Travis
From: gary...@google.com [mailto:gary...@google.com] On Behalf Of Gary
Kacmarcik (?)
Sent: Friday, November 30, 2012 2:11 PM
To: Hallvord Reiar Michaelsen Steen; public-webapps@w3.org
Subject: Re: Re: Event.key complaints?
On Thu, Nov 8, 2012 at 6:37 AM, Hallvord Reiar Michaelsen Steen wrote:
>>> Hence, what I think would be most usable in the real world would be
>>> making event.key a mapping back to un-shifted character values of a
>>> normal QUERTY (en-US) layout. Authors are asking for stable reference
>>> values for identifying keys, and that's the most stable and widely
>>> known reference keyboard layout.
Gary responded:
>> The main problem with using unmodified 'en-US' values is that it doesn't
>> define values for keys that are not found on US keyboards. So, it's great
>> for US keys, but completely ignores the rest of the world.
Hallvord replied:
> Yep, and the solution to that is listing those keys and figuring out what
> their preferred key name should be. [...]
>
> Thanks for coming up with your list :-)
That wasn't really supposed to be a list, just a few obvious problematic
examples. ^_^
However, I've spent some time over the past few weeks working to identify all
the problem cases so that we can have a more concrete proposal.
But first (for background), I extended your key event "stories" into 3 basic
scenarios that I refer to (for lack of better, unambiguous terms) as CHAR,
MEANING and CODE.
CHAR (high-level character info)
The CHAR use-case is for users who are interested only in the printable final
character that the user typed (or entered through some other means).
The user gets the char info by handling 'keypress' (deprecated) or HTML5
'input' events and reading the 'char' field from the KeyboardEvent.
Example use-case: Detect character input (to validate field after each char is
entered)
MEANING (high-level key info - virtual key meaning)
---
The MEANING use-case is for users who are interested in the meaning of the key
being pressed, taking into account the current keyboard layout (and IME and
dead keys).
Example use-case: Detect modified keys or bare modifier keys (to perform an
action in response to shortcut)
CODE (low-level key info - physical keys)
-
The CODE use-case is for users who are interested in the key that was pressed
by the user, without any layout modifications applied.
Example use-cases: Games (detect WASD keys for movement), Remote desktop client
(trap all keys to send to remote host)
I was hoping that the MEANING and CODE scenarios could be satisfied with a
single field in the KeyboardEvent structure, but further reflection has
convinced me that this is not possible.
Consider these examples that demonstrate the difference between MEANING and
CODE, and why both are needed:
Left/Right Alt key:
CHAR MEANING CODElocation
US Keyboard "" "Alt" "AltLeft"left
US Keyboard "" "Alt" "AltRight" right
French Keyboard "" "Alt" "AltLeft"standard
French Keyboard "" "AltGr" "AltRight" standard
Notes:
MEANING permits matching "Alt" regardless of which Alt key was
pressed.
CODE permits matching "AltRight" regardless of which layout is in
effect.
The location for "Alt" and "AltGr" is 'standard' since there's only one
of each key. Arguably, these values could be 'left'/'right' to match
the US layout.
Single Quote key:
CHAR MEANING CODE
US Keyboard "'" "'""Quote"
Japanese Kbd ":" ":""Quote"
US Intl Kbd """DeadAcute""Quote"
Notes:
For US Intl Kbd, we can't use the unmodified US key ("'") in the
MEANING since that's where the dead key is specified.
Equal Sign (with Left A
Re: Re: Event.key complaints?
On Thu, Nov 8, 2012 at 6:37 AM, Hallvord Reiar Michaelsen Steen wrote:
>
>>> Hence, what I think would be most usable in the real world would be
>>> making event.key a mapping back to un-shifted character values of a
>>> normal QUERTY (en-US) layout. Authors are asking for stable reference
>>> values for identifying keys, and that's the most stable and widely
>>> known reference keyboard layout.
Gary responded:
>> The main problem with using unmodified 'en-US' values is that it doesn't
>> define values for keys that are not found on US keyboards. So, it's great
>> for US keys, but completely ignores the rest of the world.
Hallvord replied:
> Yep, and the solution to that is listing those keys and figuring out what
> their preferred key name should be. [...]
>
> Thanks for coming up with your list :-)
That wasn't really supposed to be a list, just a few obvious problematic
examples. ^_^
However, I've spent some time over the past few weeks working to identify
all the problem cases so that we can have a more concrete proposal.
But first (for background), I extended your key event "stories" into 3
basic scenarios that I refer to (for lack of better, unambiguous terms) as
CHAR, MEANING and CODE.
CHAR (high-level character info)
The CHAR use-case is for users who are interested only in the printable
final character that the user typed (or entered through some other means).
The user gets the char info by handling 'keypress' (deprecated) or HTML5
'input' events and reading the 'char' field from the KeyboardEvent.
Example use-case: Detect character input (to validate field after each char
is entered)
MEANING (high-level key info - virtual key meaning)
---
The MEANING use-case is for users who are interested in the meaning of the
key being pressed, taking into account the current keyboard layout (and IME
and dead keys).
Example use-case: Detect modified keys or bare modifier keys (to perform an
action in response to shortcut)
CODE (low-level key info - physical keys)
-
The CODE use-case is for users who are interested in the key that was
pressed by the user, without any layout modifications applied.
Example use-cases: Games (detect WASD keys for movement), Remote desktop
client (trap all keys to send to remote host)
I was hoping that the MEANING and CODE scenarios could be satisfied with a
single field in the KeyboardEvent structure, but further reflection has
convinced me that this is not possible.
Consider these examples that demonstrate the difference between MEANING and
CODE, and why both are needed:
Left/Right Alt key:
CHAR MEANING CODElocation
US Keyboard "" "Alt" "AltLeft"left
US Keyboard "" "Alt" "AltRight" right
French Keyboard "" "Alt" "AltLeft"standard
French Keyboard "" "AltGr" "AltRight" standard
Notes:
MEANING permits matching "Alt" regardless of which Alt key was
pressed.
CODE permits matching "AltRight" regardless of which layout is in
effect.
The location for "Alt" and "AltGr" is 'standard' since there's only
one
of each key. Arguably, these values could be 'left'/'right' to match
the US layout.
Single Quote key:
CHAR MEANING CODE
US Keyboard "'" "'""Quote"
Japanese Kbd ":" ":""Quote"
US Intl Kbd """DeadAcute""Quote"
Notes:
For US Intl Kbd, we can't use the unmodified US key ("'") in the
MEANING since that's where the dead key is specified.
Equal Sign (with Left Alt pressed):
CHAR MEANING CODEmodifiers
US Keyboard """=""EqualSign" Alt
Korean Kbd"""JunjaMode""EqualSign" Alt
Two (with Shift key pressed):
CHAR MEANING CODE
US Keyboard "@" "@" "Digit2"
UK Keyboard """ """ "Digit2"
French Keyboard "2" "2" "Digit2"
Notes:
If we adopted MEANING = unmodified US key, then the MEANINGs would
all be "2" instead of varying. That would fix this case, but
wouldn't help the other examples given here.
Note that neither the MEANING nor the CODE is sufficient by itself to
encode the info needed for all the desired use cases.
As for where to store this information, it's clear that we need 3 separate
fields. We already have 'char' and 'key' in the spec with 'char'
corresponding to CHAR and 'key' corresponding to MEANING. I propose a new
field 'code' which encodes the CODE information.
Note that, wherever possible, the CODE names come from the US keyboard
layout. So these values will be familiar to most developers while still
satisfying the requirement to provide for a unique mapping from code name
t
Re: Re: Event.key complaints?
I wrote: >> Hence, what I think would be most usable in the real world would be >> making event.key a mapping back to un-shifted character values of a >> normal QUERTY (en-US) layout. Authors are asking for stable reference >> values for identifying keys, and that's the most stable and widely >> known reference keyboard layout. Gary responded: > The main problem with using unmodified 'en-US' values is that it doesn't > define values for keys > that are not found on US keyboards. So, it's great for US keys, but > completely ignores > the rest of the world. Yep, and the solution to that is listing those keys and figuring out what their preferred key name should be. An implementation may still run into keys that have no identifier per the spec (so the spec says that "implementations that are unable to identify a key must use the key value 'Unidentified')" - but we should do a bit of work here to make sure as few keys as possible end up in this state. Thanks for coming up with your list :-) > Consider the following problems with using 'en-US': > * What should the 'key' value be for the "B00" key (located next to the left > shift - see > the ISO/IEC9995-2 spec[1])? This is used in UK, Italian, Spanish, French, > German and many other keyboards. Several layouts place < here, some others &, \ or -. AFAIK the most common seems to be <, which also does not collide with any en-US unshifted key. * What should the 'key' value be for "B11" key (next to the right shift)? This is used on Brazilian and Japanese keyboards. Seems Brazilian layouts have / and Japanese \ here, however these already exist on US layout. I guess event.key could be '/\' (only half-serious here). Any other proposals? > * And "C12" (tucked under Enter key when Enter takes 2 rows)? Keyboards with > B00 usually have C12 as well. Go with UK and make event.key # ? > * And "E13" (between += and Backspace)? Found on Japanese (Yen key) and > Russian keyboards. With apologies to Russia, we might make event.key be ¥ for this one. (Seems some Russian layouts have \ here - but then, the "Russian" layout documened by Microsoft on http://msdn.microsoft.com/en-us/goglobal/bb964651.aspx had no less than two other keys for \). > * For B00, the USB code = 0x64, name = "Non-US \ and |". > * For B11, the USB code = 0x87, name = "International1". > * For C12, the USB code = 0x32, name = "Non-US # and ~". > * For E13, the USB code = 0x89, name = "International3". I guess names like "International1" could be used if we struggle.. > As for the solution we need to come up with, it doesn't matter to me if it's: > * encoded in the current 'key' field, or in a new field (although it'd be > nice to have > the 'key' field "do the right thing"). Sure, if we can agree on what that thing is :-) > * a numeric value or a string (although I think a numeric value is preferable > to avoid > confusion with the 'char' value). Hm.. Personally I think a numeric value would be too easily confused with the keyCode value (which authors are used to), and in many cases it would actually be the very same value. If we want to make .key a number it's tempting to suggest throwing out .key and standardising .keyCode properly instead. (Some legacy issues will make this somewhat less reliable as an "identify the key on the keyboard" solution, e.g. A's keycode moving around on the keyboard when switching from QUERTY to AZERTY). > * the exact USB codes or something similar that we derive from them. IMO it's nicer and more author-friendly to have some abstraction if we can make it easier to use.. > But, we do need it to: > * be able to uniquely identify each key on the keyboard. > * be useful for all keys on all keyboards (and not just those that map nicely > to 'en-US') > * be straightforward to implement on all platforms. I don't think we can fulfil all three - particularly not the latter. That's just the way it is :-( -- Hallvord R. M. Steen Core tester, Opera Software
Re: Event.key complaints?
On Thu 1 Nov 2012, Hallvord R. M. Steen wrote: > I would like the "story" of event.char and event.key to be that > event.char describes the generated character (if any) in its > shifted/unshifted/modified/localized glory while event.key describes > the key (perhaps on a best-effort basis, but in a way that is at least > as stable and usable as event.keyCode). I think we're mostly in agreement here (except for being satisfied with "best-effort" key codes ^_^). > Hence, what I think would be most usable in the real world would be > making event.key a mapping back to un-shifted character values of a > normal QUERTY (en-US) layout. Authors are asking for stable reference > values for identifying keys, and that's the most stable and widely > known reference keyboard layout. The main problem with using unmodified 'en-US' values is that it doesn't define values for keys that are not found on US keyboards. So, it's great for US keys, but completely ignores the rest of the world. And once you start looking at adding support for these other keys, you find that things aren't so simple. This is why we proposed using the USB codes - it defines unique values that cover pretty much every modern keyboard that's in use. Consider the following problems with using 'en-US': * What should the 'key' value be for the "B00" key (located next to the left shift - see the ISO/IEC9995-2 spec[1])? This is used in UK, Italian, Spanish, French, German and many other keyboards. * What should the 'key' value be for "B11" key (next to the right shift)? This is used on Brazilian and Japanese keyboards. * And "C12" (tucked under Enter key when Enter takes 2 rows)? Keyboards with B00 usually have C12 as well. * And "E13" (between += and Backspace)? Found on Japanese (Yen key) and Russian keyboards. None of these keys exist on a US keyboard. The USB codes solve all of these problems because they've already thought about all the keyboard variation that exists in the world: * For B00, the USB code = 0x64, name = "Non-US \ and |". * For B11, the USB code = 0x87, name = "International1". * For C12, the USB code = 0x32, name = "Non-US # and ~". * For E13, the USB code = 0x89, name = "International3". Simply specifying the 'key' codes as coming from the 'en-US' layout leaves too many details undefined and (while it may be marginally better than the legacy keyCode values) will most likely result in a lot of browser variation for these non-US "edge cases". Because of these problems, specifying this field as containing unmodified 'en-US' key is not an adequate solution. As for the solution we need to come up with, it doesn't matter to me if it's: * encoded in the current 'key' field, or in a new field (although it'd be nice to have the 'key' field "do the right thing"). * a numeric value or a string (although I think a numeric value is preferable to avoid confusion with the 'char' value). * the exact USB codes or something similar that we derive from them. But, we do need it to: * be able to uniquely identify each key on the keyboard. * be useful for all keys on all keyboards (and not just those that map nicely to 'en-US') * be straightforward to implement on all platforms. -Gary [1] See http://en.wikipedia.org/wiki/ISO/IEC_9995
Re: Event.key complaints?
On Thu, Nov 1, 2012 at 11:58 AM, Ojan Vafai wrote: > WebKit does not implement key/char, but does support keyIdentifier from an > older version of the DOM 3 Events spec. It doesn't match the current key > property in a number of ways (e.g. it has unicode values like "U+0059"), > but I do think it suffers from some of the same issues Hallvord mentioned. > On my US standard layout keyboard in Chrome, the key labeled [A] generates events with a |keyIdentifier| of "U+0041" in both shifted and unshifted state, and the key labeled [1!] generates events with a |keyIdentifier| of "U+0031" in both shifted and unshifted states. It's identifying a particular physical key on the keyboard rather than the current "meaning" of the key - so in theory it's superior in Hallvord's use case to |key| which has multiple values for the same physical key. But as Ojan points out the identification is done with Unicode code points that don't correspond at all to the character that (may) be generated, which is going to confuse developers further. Keys without "printed representation" like "Enter", "Shift", "Up", etc. are given those names for |keyIdentifier|, which is slightly more sensible. Apart from exceptions like "Tab" and "Esc", which get the U+ treatment. On Thu, Nov 1, 2012 at 7:22 AM, Travis Leithead < > travis.leith...@microsoft.com> wrote: > >> This is great feedback, which will need to be addressed one-way or >> another before we finish DOM 3 Events. >> >> Are there any other implementations of key/char other than IE9 & 10? (And >> Opera's Alpha-channel implementation). I did a quick check in the latest >> Firefox/Chrome stable branches and couldn't detect it, but wanted to be >> sure. >> >> > -Original Message- >> > From: Hallvord R. M. Steen [mailto:hallv...@opera.com] >> > Sent: Thursday, November 1, 2012 1:37 PM >> > To: Ojan Vafai >> > Cc: Travis Leithead; public-weba...@w3c.org >> > Subject: Re: Event.key complaints? >> > >> > Travis wrote: >> > >> > >> Hallvord, sorry I missed your IRC comment in today's meeting, >> > >> related to >> > >> DOM3 Events: >> > >> ** ** >> > >> event.key is still a problem child, authors >> trying >> > >> to use it have been complaining both to me and on the mailing >> > >> list >> > >> ** ** >> > >> Could you point me to the relevant discussions? >> > >> > To which Ojan Vafai replied: >> > >> > > I'm not sure what specific issues Hallvord has run into, but WebKit >> > > implementing this property is blocked on us having a bit more >> > > confidence that the key/char properties won't be changing. >> > >> > Probably wise of you to hold off a little bit ;-), and thanks for >> pointing to >> > relevant discussion threads (I pasted your links at the end). >> > >> > Opera has done the "canary" implementation of the key and char >> properties, >> > according to the current spec. As such, we've received feedback from JS >> > authors trying to code for the new implementation, both from internal >> > employees and externals. According to this feedback, although the new >> spec >> > attempts to be more i18n-friendly it is actually a step backwards >> compared to >> > the event.keyCode model: >> > >> > If, for example, you would like to do something when the user presses >> [Ctrl]- >> > [1], under the old keyCode model you could write this in a keydown >> handler: >> > >> > if(event.ctrlKey && event.keyCode == 49) >> > >> > while if you want to use the new implementation you will have to do >> > something like >> > >> > if(event.ctrlKey && ( event.key == 1 || event.key == '&' || event.key >> == '1' )) >> > >> > and possibly even more variations, depending on what locales you want to >> > support. (That's three checks for English ASCII, French AZERTY and >> Japanese >> > hiragana "wide character form" layouts respectively - I don't know of >> other >> > locales that assign other character values to this key but they might >> exist). >> > Obviously, this makes it orders of magniture harder to write >> cross-locale >> > applications and places a large burden of comp
Re: Event.key complaints?
WebKit does not implement key/char, but does support keyIdentifier from an older version of the DOM 3 Events spec. It doesn't match the current key property in a number of ways (e.g. it has unicode values like "U+0059"), but I do think it suffers from some of the same issues Hallvord mentioned. On Thu, Nov 1, 2012 at 7:22 AM, Travis Leithead < travis.leith...@microsoft.com> wrote: > This is great feedback, which will need to be addressed one-way or another > before we finish DOM 3 Events. > > Are there any other implementations of key/char other than IE9 & 10? (And > Opera's Alpha-channel implementation). I did a quick check in the latest > Firefox/Chrome stable branches and couldn't detect it, but wanted to be > sure. > > > -Original Message- > > From: Hallvord R. M. Steen [mailto:hallv...@opera.com] > > Sent: Thursday, November 1, 2012 1:37 PM > > To: Ojan Vafai > > Cc: Travis Leithead; public-weba...@w3c.org > > Subject: Re: Event.key complaints? > > > > Travis wrote: > > > > >> Hallvord, sorry I missed your IRC comment in today's meeting, > > >> related to > > >> DOM3 Events: > > >> ** ** > > >> event.key is still a problem child, authors trying > > >> to use it have been complaining both to me and on the mailing > > >> list > > >> ** ** > > >> Could you point me to the relevant discussions? > > > > To which Ojan Vafai replied: > > > > > I'm not sure what specific issues Hallvord has run into, but WebKit > > > implementing this property is blocked on us having a bit more > > > confidence that the key/char properties won't be changing. > > > > Probably wise of you to hold off a little bit ;-), and thanks for > pointing to > > relevant discussion threads (I pasted your links at the end). > > > > Opera has done the "canary" implementation of the key and char > properties, > > according to the current spec. As such, we've received feedback from JS > > authors trying to code for the new implementation, both from internal > > employees and externals. According to this feedback, although the new > spec > > attempts to be more i18n-friendly it is actually a step backwards > compared to > > the event.keyCode model: > > > > If, for example, you would like to do something when the user presses > [Ctrl]- > > [1], under the old keyCode model you could write this in a keydown > handler: > > > > if(event.ctrlKey && event.keyCode == 49) > > > > while if you want to use the new implementation you will have to do > > something like > > > > if(event.ctrlKey && ( event.key == 1 || event.key == '&' || event.key == > '1' )) > > > > and possibly even more variations, depending on what locales you want to > > support. (That's three checks for English ASCII, French AZERTY and > Japanese > > hiragana "wide character form" layouts respectively - I don't know of > other > > locales that assign other character values to this key but they might > exist). > > Obviously, this makes it orders of magniture harder to write cross-locale > > applications and places a large burden of complexity on JS authors. > > > > In the current spec, event.key and event.char are actually aliases of > each > > other for most keys on the keyboard! If the key you press doesn't have a > > "key name" string, event.key and event.char are spec'ed as being the same > > value [1]. > > > > This "aliasing" doesn't really add up to a clear concept. If two > properties have > > the same value almost always, why do we add *two* new properties in the > > first place? > > > > This is also the underlying cause for other reported problems with the > new > > model, like the inability to match [Shift]-[A] keydown/up events because > > event.key might be a in keydown but A in keyup or vice versa. > > > > I would like the "story" of event.char and event.key to be that > event.char > > describes the generated character (if any) in its > > shifted/unshifted/modified/localized glory while event.key describes the > > key (perhaps on a best-effort basis, but in a way that is at least as > stable and > > usable as event.keyCode). > > > > Hence, what I think would be most usable in the real world would be > making > > event.key a mapping back to un-shifted character values of a normal > QUERTY > > (e
RE: Event.key complaints?
This is great feedback, which will need to be addressed one-way or another before we finish DOM 3 Events. Are there any other implementations of key/char other than IE9 & 10? (And Opera's Alpha-channel implementation). I did a quick check in the latest Firefox/Chrome stable branches and couldn't detect it, but wanted to be sure. > -Original Message- > From: Hallvord R. M. Steen [mailto:hallv...@opera.com] > Sent: Thursday, November 1, 2012 1:37 PM > To: Ojan Vafai > Cc: Travis Leithead; public-weba...@w3c.org > Subject: Re: Event.key complaints? > > Travis wrote: > > >> Hallvord, sorry I missed your IRC comment in today's meeting, > >> related to > >> DOM3 Events: > >> ** ** > >> event.key is still a problem child, authors trying > >> to use it have been complaining both to me and on the mailing > >> list > >> ** ** > >> Could you point me to the relevant discussions? > > To which Ojan Vafai replied: > > > I'm not sure what specific issues Hallvord has run into, but WebKit > > implementing this property is blocked on us having a bit more > > confidence that the key/char properties won't be changing. > > Probably wise of you to hold off a little bit ;-), and thanks for pointing to > relevant discussion threads (I pasted your links at the end). > > Opera has done the "canary" implementation of the key and char properties, > according to the current spec. As such, we've received feedback from JS > authors trying to code for the new implementation, both from internal > employees and externals. According to this feedback, although the new spec > attempts to be more i18n-friendly it is actually a step backwards compared to > the event.keyCode model: > > If, for example, you would like to do something when the user presses [Ctrl]- > [1], under the old keyCode model you could write this in a keydown handler: > > if(event.ctrlKey && event.keyCode == 49) > > while if you want to use the new implementation you will have to do > something like > > if(event.ctrlKey && ( event.key == 1 || event.key == '&' || event.key == '1' > )) > > and possibly even more variations, depending on what locales you want to > support. (That's three checks for English ASCII, French AZERTY and Japanese > hiragana "wide character form" layouts respectively - I don't know of other > locales that assign other character values to this key but they might exist). > Obviously, this makes it orders of magniture harder to write cross-locale > applications and places a large burden of complexity on JS authors. > > In the current spec, event.key and event.char are actually aliases of each > other for most keys on the keyboard! If the key you press doesn't have a > "key name" string, event.key and event.char are spec'ed as being the same > value [1]. > > This "aliasing" doesn't really add up to a clear concept. If two properties > have > the same value almost always, why do we add *two* new properties in the > first place? > > This is also the underlying cause for other reported problems with the new > model, like the inability to match [Shift]-[A] keydown/up events because > event.key might be a in keydown but A in keyup or vice versa. > > I would like the "story" of event.char and event.key to be that event.char > describes the generated character (if any) in its > shifted/unshifted/modified/localized glory while event.key describes the > key (perhaps on a best-effort basis, but in a way that is at least as stable > and > usable as event.keyCode). > > Hence, what I think would be most usable in the real world would be making > event.key a mapping back to un-shifted character values of a normal QUERTY > (en-US) layout. Authors are asking for stable reference values for identifying > keys, and that's the most stable and widely known reference keyboard > layout. > > Alternatively, we can spec that event.key describes the un-shifted, un- > modified key state from the current keyboard layout AND standardise > event.keyCode they way it's already implemented rather than deprecating it, > because it covers some use cases better than what our new stuff does. But > my preference would be going the event.key = QUERTY (en-US) route, and I > plan to report a bug or two on making that happen. > -Hallvord > > [1] Spec describes event.key as follows: "If the value is has a printed > representation, it must match the value of the KeyboardEvent.char > attribute" > http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3- > Events.html#events-KeyboardEvent-key > > http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0010.html > http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0713.html > http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0103.html > http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0030.html > https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341
Re: Event.key complaints?
Travis wrote: Hallvord, sorry I missed your IRC comment in today's meeting, related to DOM3 Events: ** ** event.key is still a problem child, authors trying to use it have been complaining both to me and on the mailing list ** ** Could you point me to the relevant discussions? To which Ojan Vafai replied: I'm not sure what specific issues Hallvord has run into, but WebKit implementing this property is blocked on us having a bit more confidence that the key/char properties won't be changing. Probably wise of you to hold off a little bit ;-), and thanks for pointing to relevant discussion threads (I pasted your links at the end). Opera has done the "canary" implementation of the key and char properties, according to the current spec. As such, we've received feedback from JS authors trying to code for the new implementation, both from internal employees and externals. According to this feedback, although the new spec attempts to be more i18n-friendly it is actually a step backwards compared to the event.keyCode model: If, for example, you would like to do something when the user presses [Ctrl]-[1], under the old keyCode model you could write this in a keydown handler: if(event.ctrlKey && event.keyCode == 49) while if you want to use the new implementation you will have to do something like if(event.ctrlKey && ( event.key == 1 || event.key == '&' || event.key == '1' )) and possibly even more variations, depending on what locales you want to support. (That's three checks for English ASCII, French AZERTY and Japanese hiragana "wide character form" layouts respectively - I don't know of other locales that assign other character values to this key but they might exist). Obviously, this makes it orders of magniture harder to write cross-locale applications and places a large burden of complexity on JS authors. In the current spec, event.key and event.char are actually aliases of each other for most keys on the keyboard! If the key you press doesn't have a "key name" string, event.key and event.char are spec'ed as being the same value [1]. This "aliasing" doesn't really add up to a clear concept. If two properties have the same value almost always, why do we add *two* new properties in the first place? This is also the underlying cause for other reported problems with the new model, like the inability to match [Shift]-[A] keydown/up events because event.key might be a in keydown but A in keyup or vice versa. I would like the "story" of event.char and event.key to be that event.char describes the generated character (if any) in its shifted/unshifted/modified/localized glory while event.key describes the key (perhaps on a best-effort basis, but in a way that is at least as stable and usable as event.keyCode). Hence, what I think would be most usable in the real world would be making event.key a mapping back to un-shifted character values of a normal QUERTY (en-US) layout. Authors are asking for stable reference values for identifying keys, and that's the most stable and widely known reference keyboard layout. Alternatively, we can spec that event.key describes the un-shifted, un-modified key state from the current keyboard layout AND standardise event.keyCode they way it's already implemented rather than deprecating it, because it covers some use cases better than what our new stuff does. But my preference would be going the event.key = QUERTY (en-US) route, and I plan to report a bug or two on making that happen. -Hallvord [1] Spec describes event.key as follows: "If the value is has a printed representation, it must match the value of the KeyboardEvent.char attribute" http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-KeyboardEvent-key http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0010.html http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0713.html http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0103.html http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0030.html https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341
Re: Event.key complaints?
I'm not sure what specific issues Hallvord has run into, but WebKit implementing this property is blocked on us having a bit more confidence that the key/char properties won't be changing. Specifically, I'd like to see some rough resolution to the following threads: http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0010.html http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0713.html http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0103.html http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0030.html I'd be fine pushing the USB codes off to level 4, except it's not clear to me that we'd want the key/char properties to stay as is if we added the USB codes. On Mon, Oct 29, 2012 at 2:26 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > Hallvord, sorry I missed your IRC comment in today’s meeting, related to > DOM3 Events: > > ** ** > > event.key is still a problem child, authors trying > > to use it have been complaining both to me and on the mailing > > list > > ** ** > > Could you point me to the relevant discussions? The only issues with key > that I’ve tracked relating to the spec are regarding control key usage in > International keyboard layouts: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341. > > ** ** > > Thanks, > > -Travis >
Event.key complaints?
Hallvord, sorry I missed your IRC comment in today's meeting, related to DOM3 Events: event.key is still a problem child, authors trying to use it have been complaining both to me and on the mailing list Could you point me to the relevant discussions? The only issues with key that I've tracked relating to the spec are regarding control key usage in International keyboard layouts: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341. Thanks, -Travis
