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: Sat, 18 May 2013 09:39:43 +0900
Message-ID: <5196CDCF.5000100@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>
I filed a spec bug for discussing and adding clearer definition into the 
spec.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22081

On 2013/05/10 8:59, Masayuki Nakano wrote:
> 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 Saturday, 18 May 2013 00:40:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC