- From: Masayuki Nakano <masayuki@d-toybox.com>
- Date: 2013年5月18日 09:39:43 +0900
- 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>
- Message-ID: <5196CDCF.5000100@d-toybox.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