This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22081 - Needs to be clearer definition of "Spacebar" whether it should be used when non-ASCII space (U+20) is inputted or physical space key is pressed
Summary: Needs to be clearer definition of "Spacebar" whether it should be used when n...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-18 00:36 UTC by Masayuki Nakano
Modified: 2013-10-23 13:59 UTC (History)
3 users (show)

See Also:

Attachments

Description Masayuki Nakano 2013-05-18 00:36:49 UTC 
With some keyboard layouts, Spacebar causes other non-ASCII whitespace (U+20) such as non-breakable space (U+A0), ZWSP or some other space like character of Unicode.

On Windows and Mac, the native virtual keycode VK_SPACE and kVKSpace indicates physical spacebar key event. Therefore, if on such platform, it does make sense "Spacebar" not depend on actual input character.

On the other hand, on Linux (GTK/GDK), native key events tell keysym which indicate actual input character. And there is no strict way to know whether a native key event is caused by physical space key or not. Therefore, Firefox 23 will use "Spacebar" only when native key event causes GDK_Space keysym. That means if the space key causes non-brekable space or some other whitespace like characters, "Spacebar" isn't set to .key attribute only on Linux.

This inconsistency is too bad. So, we need to improve the consistency in the future version. For that, we need to clearer guideline for "Spacebar" in D3E spec.

Currently, D3E spec says: The Space (Spacebar) key (' ').

This explanation sounds like the "Spacebar" indicates both physical space key and a special key name for " " input key.

I believe that "Spacebar" should indicate the physical space key. I.e., it should be similar to numpad's "Devide", "Separator" and "Decimal".

Then, web applications can implement physical space key as a shortcut key with any keyboard layout.

If "Spacebar" indicates physical space key (or used for a key which inputs space like character), we can improve the Linux version of Gecko because we can check unmodified input character of each key event.

On the other hand, somebody thinks .key should indicate current function with modifier state. Therefore, "Spacebar" should be a special key name for ASCII whitespace input key. See this thread: http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0108.html

I'd like to clearer definition for this issue in D3E spec. And of course, I believe that it's better "Spacebar" to indicate the physical key rather than to be a special key name for U+20.
Comment 1 Gary Kacmarcik 2013-05-18 01:52:03 UTC 
For consistency with all the other keys, the 'key' value should always be the Unicode value with all modifier state applied (just like with the alphanumeric keys).

So 'key' =
   ' ' for normal space
   '\u00a0' for non-breaking space
   '\u3000' for full-width space
   ' ' (location=keypad) for the keypad space

If a programmer cares about the physical spacebar key, then the 'code' attribute is the proper way to identify that.

I sounds like "Spacebar" should be removed from the 'key' list.
Comment 2 Masayuki Nakano 2013-05-18 02:08:05 UTC 
(In reply to comment #1)
> I sounds like "Spacebar" should be removed from the 'key' list.

Then, if Ctrl+Space doesn't cause text input, .key value for Ctrl+Space should be the actual input character? E.g., control character or empty string?

Basically, I don't agree with the basic idea of .key for printable keys.
Comment 3 Gary Kacmarcik 2013-10-23 13:59:14 UTC 
Fixed in latest ED.

Spacebar is no longer defined as a special key value (use ' ' instead).

The ctrl-<key> issue mentioned in comment (2) was handled in a separate bug (18867) since the comment was made.