Keyboard events for accessible RIAs and Games
I have written a blog post at length about this issue here:
http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/
In short the problem is the following:
- RIAs (shortcut systems) and Games (shortcut systems and action systems)
need to be able to identify each key uniquely regardless of modifier keys
pressed.
- To make things mappable an unmodified primary symbol or description needs
to be available to display to the user.
- To make things speedy to handle there should also be an accompanying
unmodified keyCode (numeric)
The current event model (keyCode, charCode and which) do not satisfy that
requirement:
- The same keyCode appears on multiple keys
- The same charCode appears (differently from keyCode) on multiple keys
- charCode and keyCode change based on modifiers
- keyCodes cannot be converted to a users locale
- no non printable key descriptions are offered
- which is a combination of all the problems above.
It is recognized that this is not a good way to do things as for instance
the MDN already lists keyCode, charCode and which as deprecated.
The DOM Event Level 3 does not solve all these problems:
- The char member is still being delivered modified
- The key member has to match the char member for printable keys
- There is no numeric unmodified keyCode
I would suggest:
- Add a primary key symbol (printable, from the users locale) umodified and
for non printable keys add the human readable description ('backspace',
'enter' etc.)
- Add an additional unmodified key code member holding the numeric key code
unmodified
Re: Keyboard events for accessible RIAs and Games
This is not the first time these issues have been raised. The following
threads can provide some context to the current state of the discussion:
http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0103.html (obsolete
proposal)
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0623.html
Please also take a look at the UIEvents (formerly DOM Level 4 Events)
Editor's Draft at:
https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm
I believe that it addresses all of your concerns but I'm interested in any
comments that you might have.
Thanks,
-Gary
On Wed, Jan 30, 2013 at 6:05 AM, Florian Bösch pya...@gmail.com wrote:
I have written a blog post at length about this issue here:
http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/
In short the problem is the following:
- RIAs (shortcut systems) and Games (shortcut systems and action systems)
need to be able to identify each key uniquely regardless of modifier keys
pressed.
- To make things mappable an unmodified primary symbol or description
needs to be available to display to the user.
- To make things speedy to handle there should also be an accompanying
unmodified keyCode (numeric)
The current event model (keyCode, charCode and which) do not satisfy that
requirement:
- The same keyCode appears on multiple keys
- The same charCode appears (differently from keyCode) on multiple keys
- charCode and keyCode change based on modifiers
- keyCodes cannot be converted to a users locale
- no non printable key descriptions are offered
- which is a combination of all the problems above.
It is recognized that this is not a good way to do things as for instance
the MDN already lists keyCode, charCode and which as deprecated.
The DOM Event Level 3 does not solve all these problems:
- The char member is still being delivered modified
- The key member has to match the char member for printable keys
- There is no numeric unmodified keyCode
I would suggest:
- Add a primary key symbol (printable, from the users locale) umodified
and for non printable keys add the human readable description ('backspace',
'enter' etc.)
- Add an additional unmodified key code member holding the numeric key
code unmodified
Re: Keyboard events for accessible RIAs and Games
Thanks for the link to the Event Level-4, it does indeed address some of
the issues of Event Level-3 (unmodified human readable persistent key
values). There are two comments I'd like to make based on my understanding
of Event Level-4 so far.
To the first comment: The persistent description might not offer a user
something he recognizes. This becomes relevant in the case I'm arguing for
when a Web-Developer wants to construct a mapping dialog (example
screenshot
http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/blender.png
).
So for instance the (slightly contrieved) combination ctrl+shift+/+1 would
read as: CtrlKey+ShiftKey+ForwardSlash+Digit1
A possible translation to a users locale primary unmodified symbol for a
printable key is still something that is desired (and is practised by any
shortcut mapping dialog in existence).
The second comment: It is often desirable to have a numeric identifier (as
well as a string) in certain combinations of resolving events to actions. A
string necessitates usage of an object whereas a numeric identifier can be
mapped trough an array. The latter is often preferred due to JS not having
true hashes, and it might offer faster lookup (which while not particularly
relevant in realtime, may become very relevant at event replays).
On Wed, Jan 30, 2013 at 6:10 PM, Gary Kacmarcik (Кошмарчик)
gary...@chromium.org wrote:
This is not the first time these issues have been raised. The following
threads can provide some context to the current state of the discussion:
http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0103.html (obsolete
proposal)
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0623.html
Please also take a look at the UIEvents (formerly DOM Level 4 Events)
Editor's Draft at:
https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm
I believe that it addresses all of your concerns but I'm interested in any
comments that you might have.
Thanks,
-Gary
On Wed, Jan 30, 2013 at 6:05 AM, Florian Bösch pya...@gmail.com wrote:
I have written a blog post at length about this issue here:
http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/
In short the problem is the following:
- RIAs (shortcut systems) and Games (shortcut systems and action systems)
need to be able to identify each key uniquely regardless of modifier keys
pressed.
- To make things mappable an unmodified primary symbol or description
needs to be available to display to the user.
- To make things speedy to handle there should also be an accompanying
unmodified keyCode (numeric)
The current event model (keyCode, charCode and which) do not satisfy that
requirement:
- The same keyCode appears on multiple keys
- The same charCode appears (differently from keyCode) on multiple keys
- charCode and keyCode change based on modifiers
- keyCodes cannot be converted to a users locale
- no non printable key descriptions are offered
- which is a combination of all the problems above.
It is recognized that this is not a good way to do things as for instance
the MDN already lists keyCode, charCode and which as deprecated.
The DOM Event Level 3 does not solve all these problems:
- The char member is still being delivered modified
- The key member has to match the char member for printable keys
- There is no numeric unmodified keyCode
I would suggest:
- Add a primary key symbol (printable, from the users locale) umodified
and for non printable keys add the human readable description ('backspace',
'enter' etc.)
- Add an additional unmodified key code member holding the numeric key
code unmodified
Re: Keyboard events for accessible RIAs and Games
On Wed, Jan 30, 2013 at 8:20 PM, Wez w...@chromium.org wrote: Would a French user expect such a dialog to say Now press Ctrl+Shift+/+, though? I think that users expect shortcut mappers to show them the unmodified primary symbol of the key. For instance for a swiss guy the shortcut ctrl+shift+ö is expected for the pressing of the key ö which is modified by shift to be é but that's not what you'd expect. Likewise an Arabic keyboard user would probably expect ctrl+shift+ج and neither of ctrl+shift+ or ctrl+shift+Jeem or ctrl+shift+Comma. Another example would be the numeric (non numpad) key 1 which is modified by shift to be = in english but to be + in german. Neither of ctrl+shift++ nor ctrl+shift+= is expected by either keyboard layout user, what's expected is ctrl+shift+1.
Re: Keyboard events for accessible RIAs and Games
I've just been thinking about shortcut presets. And it occurs to me that it wouldn't be possible to store localized characters would not be feasible to store that. The character matter because users know where they are on their keyboards. But for a preset it really want store the keycode (numeric, unmodified) and then translate that to a localized display. A lot of shortcuts will make sense regardless of locality, but it's important for a user to figure out which shortcuts don't work for them by looking at the shortcut display. On Wed, Jan 30, 2013 at 8:37 PM, Florian Bösch pya...@gmail.com wrote: On Wed, Jan 30, 2013 at 8:20 PM, Wez w...@chromium.org wrote: Would a French user expect such a dialog to say Now press Ctrl+Shift+/+, though? I think that users expect shortcut mappers to show them the unmodified primary symbol of the key. For instance for a swiss guy the shortcut ctrl+shift+ö is expected for the pressing of the key ö which is modified by shift to be é but that's not what you'd expect. Likewise an Arabic keyboard user would probably expect ctrl+shift+ج and neither of ctrl+shift+ or ctrl+shift+Jeem or ctrl+shift+Comma. Another example would be the numeric (non numpad) key 1 which is modified by shift to be = in english but to be + in german. Neither of ctrl+shift++ nor ctrl+shift+= is expected by either keyboard layout user, what's expected is ctrl+shift+1.
Re: Keyboard events for accessible RIAs and Games
On Wed, Jan 30, 2013 at 9:31 AM, Florian Bösch pya...@gmail.com wrote: To the first comment: The persistent description might not offer a user something he recognizes. This becomes relevant in the case I'm arguing for when a Web-Developer wants to construct a mapping dialog (example screenshot http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/blender.png ). So for instance the (slightly contrieved) combination ctrl+shift+/+1 would read as: CtrlKey+ShiftKey+ForwardSlash+Digit1 A possible translation to a users locale primary unmodified symbol for a printable key is still something that is desired (and is practised by any shortcut mapping dialog in existence). Yes, trying to match the current (virtual) keycap was not a direct goal, but adding the 'code' attribute makes it possible (when combined with the current layout) to calculate a keycap value. But I don't believe that this info belongs directly in the key event: * We already have 2 (or 3) key attributes that encode the key information and this would require adding one more. Adding yet another would make the key events even more confusing to users. * This functionality is useful outside of key events. For the key pref dialog example that you gave, I assume that I'd have the 'code' (saved in a pref file or something) and I'd combine it with the current layout to get a value to display in the dialog. This would work even if the user changed keyboard layouts. So I definitely think we should provide the ability to get the keycap from the key event, but I think a general API is preferable to encoding it in the key event. The second comment: It is often desirable to have a numeric identifier (as well as a string) in certain combinations of resolving events to actions. A string necessitates usage of an object whereas a numeric identifier can be mapped trough an array. The latter is often preferred due to JS not having true hashes, and it might offer faster lookup (which while not particularly relevant in realtime, may become very relevant at event replays). We initially proposed numeric identifiers (seeded with USB usage codes to start), but got feedback that in the Web Platform constants should be string rather than ints. Using strings also makes the code self-documenting (compare if (key.code == 49)... with if (key.code == 'Digit1')...). Javascript performance is really a separate issue from this spec. Given the tradeoff between code-readability and possible performance issues, I will generally prefer code readability. In this case, even if I saw measured performance issues with current JS implementation, I would still probably opt for readability because I expect that JS perf (in all browsers) will increase faster than this spec will be updated. -Gary
[Bug 18045] Based on my experience and from reading many questions on the Web, this API is seriously flawed. It treats cross-domain iframes the same as same-domain iframes, except that almost every
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18045 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch --- *** This bug has been marked as a duplicate of bug 15942 *** -- You are receiving this mail because: You are on the CC list for the bug.
Re: Keyboard events for accessible RIAs and Games
On Wed, Jan 30, 2013 at 9:02 PM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: Yes, trying to match the current (virtual) keycap was not a direct goal, but adding the 'code' attribute makes it possible (when combined with the current layout) to calculate a keycap value. I think that would probably be the most preferable solution. The code would be stored (in presets, preferences etc.) and the keycap (primary unmodified key display for a printable key) would be queried for a code whenever it's necessary to display to a user. Let's set aside that consideration for a numeric keycode (it's a minor concern anyway).
Re: Keyboard events for accessible RIAs and Games
What/where would be a good place to put the API for say queryKeyCap(code) ? On Wed, Jan 30, 2013 at 9:38 PM, Florian Bösch pya...@gmail.com wrote: On Wed, Jan 30, 2013 at 9:02 PM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: Yes, trying to match the current (virtual) keycap was not a direct goal, but adding the 'code' attribute makes it possible (when combined with the current layout) to calculate a keycap value. I think that would probably be the most preferable solution. The code would be stored (in presets, preferences etc.) and the keycap (primary unmodified key display for a printable key) would be queried for a code whenever it's necessary to display to a user. Let's set aside that consideration for a numeric keycode (it's a minor concern anyway).
Re: Keyboard events for accessible RIAs and Games
I was wondering that myself... On Wed, Jan 30, 2013 at 12:58 PM, Florian Bösch pya...@gmail.com wrote: What/where would be a good place to put the API for say queryKeyCap(code) ? On Wed, Jan 30, 2013 at 9:38 PM, Florian Bösch pya...@gmail.com wrote: On Wed, Jan 30, 2013 at 9:02 PM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: Yes, trying to match the current (virtual) keycap was not a direct goal, but adding the 'code' attribute makes it possible (when combined with the current layout) to calculate a keycap value. I think that would probably be the most preferable solution. The code would be stored (in presets, preferences etc.) and the keycap (primary unmodified key display for a printable key) would be queried for a code whenever it's necessary to display to a user. Let's set aside that consideration for a numeric keycode (it's a minor concern anyway).
[Bug 20833] New: Incomplete sentence in draft WD-IndexedDB-20120524
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20833 Bug ID: 20833 Summary: Incomplete sentence in draft WD-IndexedDB-20120524 Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API Assignee: dave.n...@w3.org Reporter: kamat...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org I hope this is the right place to report incomplete sentences in draft. If not, kindly let me know. If you navigate to http://www.w3.org/TR/2012/WD-IndexedDB-20120524/ And search for This applies both to modifications that happen due to the current number getting increased by 1 when the key generator is used, and to modifications that happen due to You will find that the sentence has been left incomplete. -- You are receiving this mail because: You are on the CC list for the bug.
