W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2012

[Bug 18341] New: Needs some guidelines for computing key and char values of KeyboardEvent when some modifier key is pressed and not causes text input

From: <bugzilla@jessica.w3.org>
Date: Fri, 20 Jul 2012 05:40:12 +0000
To: www-dom@w3.org
Message-ID: <bug-18341-4009@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341

           Summary: Needs some guidelines for computing key and char
                    values of KeyboardEvent when some modifier key is
                    pressed and not causes text input
           Product: WebAppsWG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM3 Events
        AssignedTo: schepers@w3.org
        ReportedBy: masayuki@d-toybox.com
         QAContact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org


I think that D3E spec should provide some guidelines for computing key and char
values of printable keys with some modifier keys.

For example, in most keyboard layout on Win/Mac/Linux, printable keys with Ctrl
key doesn't cause text input. Only in this case, there is an example in current
spec:

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keys-Modifiers

This example describes the case for Latin keyboard layouts. Ctrl+'V' causes 'v'
for both key and char attributes.

However, how about the cases: if the keyboard layout is not Latin inputable
layout such as Arabic or Cyrillic?

I think that if Web applications want to handle such key events as a shortcut
key on the page, they may want to know a Latin character of the key. Otherwise,
they may want to know an unmodified character of the key.

I have some ideas. Fortunately, there are two attributes, key and char.

If the char value is same as unmodified (except shift) char, one of the
attributes can be unmodified (except shift) character, the other can be Latin
inputtable keyboard layout's character of the key. I think the former should be
char, the latter should be key.

If the Latin character of the key isn't computable (e.g., OS's limitation) or
the computed character is neither alphabet nor numeric, use same value of char.
(If we would use this rules for other symbolic characters like punctuations,
two or more keys might indicate same key attribute values, it's not good case
for me)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Friday, 20 July 2012 05:40:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 July 2012 05:40:19 GMT