Re: ISSUE-23 (Key Indentifier Case): Should Key Identifiers prioritize uppercase characters [DOM3 Events]
Web Applications Working Group Issue Tracker:
In the current draft of Key Identifiers, including the new algorithm
wording, there is a bias toward uppercase characters. Essentially, if
a key is pressed that gives a character codepoint which is lowercase,
for which there is an uppercase equivalent, the uppercase codepoint
(or character) is returned instead. What is the use case here?
The intention of that algorithm (if I remember my intention correctly
when writing it) is to provide guidance for implementors in choosing a
key identifier for a given key. For example the 'A' key on many
keyboards (like QWERTY) has a primary function (i.e. without modifiers
pressed or locks enabled) of generating an 'a' character. Given that
keyboards usually have the uppercase character printed on the keys,
using 'A' seemed to be nicer than 'a' as a key identifier.
Case is a peculiar feature of Latinate languages, and it's not clear
that special-casing it makes it easier to make reliable script. More
reliable and flexible comparisons can be made easily; compare the
following pseudocode snippets:
// keyIdentifier reports only Q, and forces all upper and lower case
characters to the uppercase value
if ( evt.keyIdentifier == Q ) { ... }
// keyIdentifier reports both Q and q, and allows authors to
// distinguish upper and lower case letters or lump them together, as
// desired
if ( evt.keyIdentifier.toLowerCase() == q ) { ... }
I’ve yet to see a keyboard that has a key for lowercase 'q' and
uppercase 'Q', so I don’t know that it makes sense to have two different
key identifiers for them. Given the fact that the 'U+0051'-style of key
identifier is awkward, we should choose either 'Q' or 'q' here.
Converting to uppercase strikes me as needless legacy from
keyCode/charCode. Is there some pragmatic reason to force this
casting?
These strings are meant to represent keys, rather than characters of
input.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: ISSUE-23 (Key Indentifier Case): Should Key Identifiers prioritize uppercase characters [DOM3 Events]
Hi, Cameron- CCing i18n folks; for reference, please see: http://www.w3.org/2008/webapps/track/issues/23 Cameron McCormack wrote (on 6/29/08 3:47 AM): Web Applications Working Group Issue Tracker: In the current draft of Key Identifiers, including the new algorithm wording, there is a bias toward uppercase characters. Essentially, if a key is pressed that gives a character codepoint which is lowercase, for which there is an uppercase equivalent, the uppercase codepoint (or character) is returned instead. What is the use case here? The intention of that algorithm (if I remember my intention correctly when writing it) is to provide guidance for implementors in choosing a key identifier for a given key. For example the 'A' key on many keyboards (like QWERTY) has a primary function (i.e. without modifiers pressed or locks enabled) of generating an 'a' character. Given that keyboards usually have the uppercase character printed on the keys, using 'A' seemed to be nicer than 'a' as a key identifier. ... I’ve yet to see a keyboard that has a key for lowercase 'q' and uppercase 'Q', so I don’t know that it makes sense to have two different key identifiers for them. Given the fact that the 'U+0051'-style of key identifier is awkward, we should choose either 'Q' or 'q' here. Converting to uppercase strikes me as needless legacy from keyCode/charCode. Is there some pragmatic reason to force this casting? These strings are meant to represent keys, rather than characters of input. A reasonable argument, but I would counter that the keys are simply mislabeled, because of long-ago imprecision on typewriters that we need not perpetuate. The identity of the key is not what is printed on the keycap, but what the operating system thinks the key is, at the time that the key is pressed. When I hit the key labeled 1 on my keyboard with no modifiers, it generated the character 1 (intuitive enough); with the shift modifier, it generates the character !. Both of those characters are printed on the key, as it happens: 1|!; the key identifiers set naturally includes both characters. By contrast, when I hit the key labeled Q on my keyboard with no modifiers, it generates the character q, and only generates the character Q when it is modified with shift or capslock. So, really, the label should read q|Q, and we should provide key identifiers for both upper- and lower-case characters. Further, when a QWERTY keyboard is remapped to a Dvorak layout, but the labels on the keys remain unchanged, a typist would expect that hitting the key labeled Q would result in an apostrophe... they would expect the same behavior if they had bothered switching the keycaps, as well as remapping. If they were asked to type Q or q, they would naturally hit the key that, on my keyboard, is labeled X. The same goes for any remapping, such as when an US keyboard is repurposed to some other alphabet. We've already determined that we can not and should not identify a key by keyboard layout, i.e. the physical position of the keys; the same applies to what is printed on the keycap, even more so. If the Director deems it necessary, in the course of Rec-track transition, for DOM3 Events to represent only the values that are printed on the keycap, I will take an action to go door-to-door and manually correct each keyboard (by force if necessary). I am aware that this may take some time (even weeks, perhaps), but I believe that that would be a more logical and pragmatic approach than for DOM3 Events to munge all Latinate characters into the uppercase. We all know that typing in all caps is rude, and forcing all keyboard events to SHOUT would degrade the bounds of polite society. Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
Re: ISSUE-23 (Key Indentifier Case): Should Key Identifiers prioritize uppercase characters [DOM3 Events]
Hi Doug. Doug Schepers: Converting to uppercase strikes me as needless legacy from keyCode/charCode. Is there some pragmatic reason to force this casting? Cameron McCormack: These strings are meant to represent keys, rather than characters of input. Doug Schepers: A reasonable argument, but I would counter that the keys are simply mislabeled, because of long-ago imprecision on typewriters that we need not perpetuate. The identity of the key is not what is printed on the keycap, but what the operating system thinks the key is, at the time that the key is pressed. You’re saying that the alphabetic keys on western keyboards are mislabelled with uppercase letters, when they should have lowercase letters on them? I think it’s just a styling issue, really. I could live with the key identifier being the lowercase letter, but given that we should choose one or the other, the uppercase letter is more consistent with the other identifiers (none of which start with a lowercase letter). When I hit the key labeled 1 on my keyboard with no modifiers, it generated the character 1 (intuitive enough); with the shift modifier, it generates the character !. Both of those characters are printed on the key, as it happens: 1|!; the key identifiers set naturally includes both characters. The only reason for including a key identifier for ! would be if there were a keyboard that had a key whose primary function is to generate a U+0021 character. On my QWERTY keyboard, I wouldn’t expect the ! key identifier ever to be used in a KeyboardEvent (instead, the 1 key identifier would be used, and shiftKey would be true). By contrast, when I hit the key labeled Q on my keyboard with no modifiers, it generates the character q, and only generates the character Q when it is modified with shift or capslock. So, really, the label should read q|Q, and we should provide key identifiers for both upper- and lower-case characters. I agree that the key is acting like q|Q. I would only agree that there should be identifiers for both q and Q if there are likely to be keyboards that have a key whose primary function is to generate an uppercase Q character. I don’t know of such a keyboard, but perhaps we don’t want to rule this out, in which case I would advise using the lowercase letter as the key identifier. Further, when a QWERTY keyboard is remapped to a Dvorak layout, but the labels on the keys remain unchanged, a typist would expect that hitting the key labeled Q would result in an apostrophe... they would expect the same behavior if they had bothered switching the keycaps, as well as remapping. If they were asked to type Q or q, they would naturally hit the key that, on my keyboard, is labeled X. The same goes for any remapping, such as when an US keyboard is repurposed to some other alphabet. Of course, but there is already wording in that algorithm to take the keyboard layout mapping into account. We've already determined that we can not and should not identify a key by keyboard layout, i.e. the physical position of the keys; the same applies to what is printed on the keycap, even more so. It’s not what is printed on the keycap that is important, but the function of the key subject to the keyboard layout mapping. But we are trying to identify a single key, and not what functions it may have under different modifiers, yes? -- Cameron McCormack ≝ http://mcc.id.au/
[D3E] Multiple keyboard identifiers
I notice that the list of keyboard identifiers in http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset now has multiple identifiers for certain keys. For example, there are three identifiers for the comma key: ,, Comma and U+002C. What is the purpose of having multiple identifiers for the one key? I think there should be only one. If you do have multiple identifiers, then you need one of them to be the “canonical” identifier that is stored in KeyboardEvent.keyIdentifier. Some other minor points: ▪ “are comprised of” should be “comprise”, in the definition of the “Unicode character categories” term. ▪ “Asterix” should be “Asterisk” in the key identifiers set section. -- Cameron McCormack ≝ http://mcc.id.au/
Re: ISSUE-23 (Key Indentifier Case): Should Key Identifiers prioritize uppercase characters [DOM3 Events]
Hi Cameron, Cameron McCormack wrote: Hi Doug. Doug Schepers: Further, when a QWERTY keyboard is remapped to a Dvorak layout, but the labels on the keys remain unchanged, a typist would expect that hitting the key labeled Q would result in an apostrophe... they would expect the same behavior if they had bothered switching the keycaps, as well as remapping. If they were asked to type Q or q, they would naturally hit the key that, on my keyboard, is labeled X. The same goes for any remapping, such as when an US keyboard is repurposed to some other alphabet. Of course, but there is already wording in that algorithm to take the keyboard layout mapping into account. We've already determined that we can not and should not identify a key by keyboard layout, i.e. the physical position of the keys; the same applies to what is printed on the keycap, even more so. It’s not what is printed on the keycap that is important, but the function of the key subject to the keyboard layout mapping. But we are trying to identify a single key, and not what functions it may have under different modifiers, yes? Out of interest, how does the algorithm take that into account. for my default layout the keystrokes that normally produce q|Q produce ŋ|Ŋ inɛtead, and i need to type AltGr+q/AltGr+Q to get q|Q my system input local is en-AU, keyboard driver is customised to specific African languages, and physical keyboard is standard qwerty. I'm curious how the algorithm will handle undefined input locales, or keyboard drivers that are forced to use the wrong input locale (which in theory is most of the languages in the world at the moment). As far as i can see there is no way for an application to know what keystrokes are being used and extrapolate what character was intended from the sequence, esp. if more sophisticated processing and reordering is occurring within a driver before the character is past to an application. At best you might be able to determine what keystrokes are used (maybe not always) and what characters are ultimately generated, although characters generated may not be in the same order as keystrokes that generate those characters. -- Andrew Cunningham Vicnet Research and Development Coordinator State Library of Victoria 328 Swanston Street Melbourne VIC 3000 Ph: +61-3-8664-7430 Fax: +61-3-9639-2175 Email: [EMAIL PROTECTED] Alt email: [EMAIL PROTECTED] http://home.vicnet.net.au/~andrewc/ http://www.openroad.net.au http://www.vicnet.net.au http://www.slv.vic.gov.au begin:vcard fn:Andrew Cunningham n:Cunningham;Andrew org:State Library of Victoria;Vicnet adr:;;328 Swanston Street;Melbourne;VIC;3000;Australia email;internet:[EMAIL PROTECTED] title:Research and Development Coordinator tel;work:+61-3-8664-7430 tel;fax:+61-3-9639-2175 tel;cell:0421-450-816 x-mozilla-html:FALSE url:http://www.openroad.net.au/ version:2.1 end:vcard
Re: ISSUE-23 (Key Indentifier Case): Should Key Identifiers prioritize uppercase characters [DOM3 Events]
Hi Andrew. Andrew Cunningham: I guess I'm not following this. So you're just looking at the scan codes then of the keys being pressed? if i press the q/Q key are you looking at a particular physical key key on the keyboard? i.e. ultimately at the scan codes or virtual key codes? or are you looking at a higher level? Yeah that’s right, that level of virtual key codes is what we want to expose via the KeyboardEvent interface, but with platform independent names for the keys. i.e. the q/Q key on a QWERTY keyboard is a different physical key than the q|Q key on a AZERTY keyboard. No. So are you using a positional approach using the virtual keys or scan codes of the physical keyboard, or are you interpreting the keystroke at a higher level so that key interpretation is mnemonic, i.e. does it matter which key is typed? or is it the q-key independent of the physical position of the q|Q key on the keyboard? Not a positional approach, since we don’t want to go down the road of physical keyboard layouts, but yes the key with identifier Q would be the one that generates q characters (or Q when shift is held, or something completely different if an IME is in use). I believe that is the intention, anyway. Do you mind if I forward this exchange back to public-webapps and public-i18n-core? Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: ISSUE-23 (Key Indentifier Case): Should Key Identifiers prioritize uppercase characters [DOM3 Events]
Cameron McCormack wrote: So are you using a positional approach using the virtual keys or scan codes of the physical keyboard, or are you interpreting the keystroke at a higher level so that key interpretation is mnemonic, i.e. does it matter which key is typed? or is it the q-key independent of the physical position of the q|Q key on the keyboard? Not a positional approach, since we don’t want to go down the road of physical keyboard layouts, but yes the key with identifier Q would be the one that generates q characters (or Q when shift is held, or something completely different if an IME is in use). I believe that is the intention, anyway. It sounds confused to me, as far as i can tell you're trying to use positional keyboard concepts in a mnemonic way. A q|Q on a QWERTY keyboard will have different scan codes and virtual key codes that the q|Q key on an AZERTY keyboard. so if you want a q|Q key on a US keyboard or a French keyboard to do the same thing on a web app, you're talking about a higher level interpretation of what a keyboard is doing. I.e. you're looking at output rather than at physical keys. unless i'm misunderstanding what you're trying to do. if you want input locale independent nomenclature for the keys, then maybe use ISO-9995 based terminology, but that's all positional. So are most virtual key naming conventions I've come across. Do you mind if I forward this exchange back to public-webapps and public-i18n-core? yes, feel free. I'm on the public-i18n-core list. Andrew -- Andrew Cunningham Vicnet Research and Development Coordinator State Library of Victoria 328 Swanston Street Melbourne VIC 3000 Ph: +61-3-8664-7430 Fax: +61-3-9639-2175 Email: [EMAIL PROTECTED] Alt email: [EMAIL PROTECTED] http://home.vicnet.net.au/~andrewc/ http://www.openroad.net.au http://www.vicnet.net.au http://www.slv.vic.gov.au begin:vcard fn:Andrew Cunningham n:Cunningham;Andrew org:State Library of Victoria;Vicnet adr:;;328 Swanston Street;Melbourne;VIC;3000;Australia email;internet:[EMAIL PROTECTED] title:Research and Development Coordinator tel;work:+61-3-8664-7430 tel;fax:+61-3-9639-2175 tel;cell:0421-450-816 x-mozilla-html:FALSE url:http://www.openroad.net.au/ version:2.1 end:vcard
Re: ISSUE-23 (Key Indentifier Case): Should Key Identifiers prioritize uppercase characters [DOM3 Events]
Andrew Cunningham: It sounds confused to me, as far as i can tell you're trying to use positional keyboard concepts in a mnemonic way. It’s quite possible I’m confused. :) A q|Q on a QWERTY keyboard will have different scan codes and virtual key codes that the q|Q key on an AZERTY keyboard. Even when the AZERTY keyboard is being used with an AZERTY keyboard layout chosen in the OS? so if you want a q|Q key on a US keyboard or a French keyboard to do the same thing on a web app, you're talking about a higher level interpretation of what a keyboard is doing. I.e. you're looking at output rather than at physical keys. I think what we want is the level just underneath the IME. (Current editors of the DOM 3 Events spec, chime in if that’s not correct.) To take a couple of examples: Using a QWERTY keyboard with a QWERTY keyboard layout chosen in the OS: ▪ Regardless of the locks enabled or modifiers pressed, pressing the key labelled Q would result in a KeyboardEvent with key identifier Q being dispatched. Using a QWERTY keyboard with an AZERTY keyboard layout chosen in the OS: ▪ Regardless of the locks enabled or modifiers pressed, pressing the key labelled Q would result in a KeyboardEvent with key identifier A being dispatched. Using a AZERTY keyboard with an QWERTY keyboard layout chosen in the OS: ▪ Regardless of the locks enabled or modifiers pressed, pressing the key labelled Q would result in a KeyboardEvent with key identifier Q being dispatched. It might be the “regardless of keyboard locks enabled” bit that is tripping me up, though. Taking another example of using a standard Korean keyboard (called Dubeolshik (두벌식) according to the wikipedia article I’m looking at) with the corresponding keyboard layout chosen in the OS: ▪ Pressing the key just to the right of Tab would generate a KeyboardEvent with key identifier ㅂ, since that key’s primary function is to generate the ㅂ jamo. If Shift were pressed at the same time, you would still get ㅂ rather than ㅃ. But now what if the Ha/En key were pressed before pressing that key to the right of Tab? Should we consider this key just like caps lock (so that pressing the key to the right of Tab still generates a ㅂ instead of a Q key identifier)? Or should we consider that the keyboard layout has actually changed, and so use Q? unless i'm misunderstanding what you're trying to do. Perhaps I should get confirmation from the other people working on DOM 3 Events about what exact KeyboardEvent is meant to be. :) if you want input locale independent nomenclature for the keys, then maybe use ISO-9995 based terminology, but that's all positional. So are most virtual key naming conventions I've come across. Positional being things like “the third key on the second row”? Do you mind if I forward this exchange back to public-webapps and public-i18n-core? yes, feel free. I'm on the public-i18n-core list. Done. If you could include those two lists in any reply that’d be helpful. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: ISSUE-23 (Key Indentifier Case): Should Key Identifiers prioritize uppercase characters [DOM3 Events]
Cameron McCormack wrote: Andrew Cunningham: so if you want a q|Q key on a US keyboard or a French keyboard to do the same thing on a web app, you're talking about a higher level interpretation of what a keyboard is doing. I.e. you're looking at output rather than at physical keys. I think what we want is the level just underneath the IME. (Current editors of the DOM 3 Events spec, chime in if that’s not correct.) To take a couple of examples: Using a QWERTY keyboard with a QWERTY keyboard layout chosen in the OS: ▪ Regardless of the locks enabled or modifiers pressed, pressing the key labelled Q would result in a KeyboardEvent with key identifier Q being dispatched. Using a QWERTY keyboard with an AZERTY keyboard layout chosen in the OS: ▪ Regardless of the locks enabled or modifiers pressed, pressing the key labelled Q would result in a KeyboardEvent with key identifier A being dispatched. Using a AZERTY keyboard with an QWERTY keyboard layout chosen in the OS: ▪ Regardless of the locks enabled or modifiers pressed, pressing the key labelled Q would result in a KeyboardEvent with key identifier Q being dispatched. ok, so more of a mnemonic approach, as far as i can tell. I'd assume that you'd need to know what keyboard layout is currently being used in order to know what key identifier is being dispatched. What happens if the keyboard layout can't be identified? I'm using Windows Vista (International English) with an input locale set to English (Australian), the physical keyboard is QWERTY (US layout), but the keyboard layout i'm typing with is something completely different. How would a web application know if typed q? since q isn't assigned to level one of the layout I'm using? I can see how it can know i pressed a key that generated a scan code that signified a q key on a QWERTY keyboard, but without looking at the output how would the application actually know? I input locale would imply that i'd used a key associated with key identifier q, but if I understand what you mean correctly, I've actually typed the key associated with key identifier ŋ. If this makes sense Just trying to figure out how African or South East Asian keyboard layouts would work, esp. visual rather than logical keyboards, where the order of keystroke and character output may be different. What would happen if the key identifier was a combining diacritic or a Myanmar medial character? would that be ok? could be some interesting text rendering issues within code, or the need to develop very specialised fonts specifically for writing code for web applications. Are there restrictions on the names of key identifiers? And would this mean there is a restriction on what keys can be used within a web application? if you want input locale independent nomenclature for the keys, then maybe use ISO-9995 based terminology, but that's all positional. So are most virtual key naming conventions I've come across. Positional being things like “the third key on the second row”? yes -- Andrew Cunningham Vicnet Research and Development Coordinator State Library of Victoria 328 Swanston Street Melbourne VIC 3000 Ph: +61-3-8664-7430 Fax: +61-3-9639-2175 Email: [EMAIL PROTECTED] Alt email: [EMAIL PROTECTED] http://home.vicnet.net.au/~andrewc/ http://www.openroad.net.au http://www.vicnet.net.au http://www.slv.vic.gov.au begin:vcard fn:Andrew Cunningham n:Cunningham;Andrew org:State Library of Victoria;Vicnet adr:;;328 Swanston Street;Melbourne;VIC;3000;Australia email;internet:[EMAIL PROTECTED] title:Research and Development Coordinator tel;work:+61-3-8664-7430 tel;fax:+61-3-9639-2175 tel;cell:0421-450-816 x-mozilla-html:FALSE url:http://www.openroad.net.au/ version:2.1 end:vcard
heads-up: /2006/webapi/Binding4DOM moved to /2006/webapi/WebIDL
I just now moved the /2006/webapi/Binding4DOM directory on the dev.w3.org CVS server to /2006/webapi/WebIDL. http://dev.w3.org/cvsweb/2006/webapi/WebIDL/ So you might get some warnings or other unexpected cvs client behavior if/when you got update your /2006/webapi working directory. To prevent that, you might want to just check in any pending changes you have in your local working directory, then move your existing webapi directory to webapi-old (or something), then check out a fresh copy of the whole directory. That is: cd 2006 cvs commit webapi mv webapi webapi-old cvs update -dP webapi If you do run into any cvs client problems that you can't figure out, please let me know right away. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ smime.p7s Description: S/MIME cryptographic signature
