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

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.

Thanks,

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