W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: [DOM3 Events] space key should be always "Spacebar" for KeyboardEvent.key?

From: Masayuki Nakano <masayuki@d-toybox.com>
Date: Fri, 10 May 2013 08:59:10 +0900
Message-ID: <518C384E.1000305@d-toybox.com>
To: Wez <wez@google.com>, "Hallvord R. M. Steen" <hallvord@opera.com>
CC: "www-dom@w3.org" <www-dom@w3.org>, Karl Tomlinson <karlt@mozbugz.karlt.net>, "Gary Kacmarcik (?????????)" <garykac@chromium.org>, Travis Leithead <travis.leithead@microsoft.com>
Then, on Windows, even if the virtual keycode is VK_SPACE, browser needs 
to check whether it's inputting ASCII space (U+20)? And also, on Mac, 
even if the virtual keycode is kVK_Space, browser needs to check whether 
it's inputting ASCII space (U+20)?

I feel it doesn't make sense. I have no idea such behavior is better for 
web developers in what cases.

If D3E spec thinks Spacebar is a printable key, why it gives special 
name "Spacebar"? I think that just " " is enough for it.

Additionally, how about the case when Ctrl or Alt key is pressed? Then, 
the .key value becomes "Spacebar" because its function doesn't input a 
character (rule 2.1).

Like "Decimal", I think that "Spacebar" should be a logical (or 
physical) name instead of a special name for a particular character 
input key.

Even with this comment, do you still think the .key value should be the 
actual input character?

FYI: .char would be dropped and textinput event would be back, instead.


On 2013/05/10 8:44, Wez wrote:
> On 9 May 2013 15:09, Hallvord R. M. Steen <hallvord@opera.com
> <mailto:hallvord@opera.com>> wrote:
>     Siterer Wez <wez@google.com <mailto:wez@google..com>>:
>         In D3E the 'key' field indicates the meaning of the key in the
>         current
>         context, so in this case it would be appropriate for it to have
>         distinct
>         values for each of the cases listed.
>     I disagree. This use case is fulfilled by the D3E "char" property,
>     no? The point of having the "key" property is to have a more stable
>     reference to whatever physical key was pressed.
> No, that's what D4E 'code' provides, hence my mentioning it below. :)
> 'key' describes the meaning of the key in the context of the current
> keyboard layout, lock states and modifiers. If the user re-maps a key's
> meaning then 'key' will reflect that, whereas D4E 'code' wouldn't.
> 'char' conveys printable characters resulting from input, and in the
> presence of dead-keys, IMEs, etc, becomes meaningless on keydown or
> keyup events - it's been proposed that 'char' on those events be
> replaced by re-introducing 'textInput' events as per earlier D3E revisions.
>     IMHO..
>         The D4E 'code' field is intended to
>         indicate the actual key that was pressed, regardless of its
>         meaning in the
>         current context, so that would be consistent for the spacebar,
>         regardless
>         of the generated KeySym.
>     The question was about the interpretation of D3E though.
>         In this case I'd recommend:
>         * For the "space" and "KP_Space" key-syms, generate Spacebar
>         (NORMAL) and
>         Spacebar (KEYPAD) events, respectively.
>         * For the others, generate events using the corresponding
>         Unicode code
>         point for the 'key' field.
>     And I would suggest that setting 'char' to the corresponding Unicode
>     code point and 'key' to "Spacebar' is the best way to fulfil all the
>     various use cases.
>     -Hallvord

Masayuki Nakano <masayuki@d-toybox.com>
Manager, Internationalization, Mozilla Japan.
Received on Friday, 10 May 2013 00:00:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:02 UTC