Git Product home page Git Product logo

uievents's Introduction

UI Events

This repository is for the UI Events specification (formerly known as DOM 3 Events).

Goals

The goal of the UI/DOM Events sub-group, part of the Web Applications Working Group, is to complete the UI Events specification according to market needs, to drive its adoption and implementation, to provide a comprehensive test suite (for implementability at least, and hopefully for interoperability, too), and to move it along the Recommendation Track to W3C Recommendation status.

Communication

For discussion of matters related to DOM Events, the group uses the [email protected] mailing list (archive).

Documents

Open Issues

Building

This spec was created using bikeshed. If you would like to contribute edits, please make sure that your changes build correctly.

To build this spec:

  1. Clone this repo into a local directory.
  2. Install bikeshed
  3. Run python build.py in your local directory.

To make edits to the spec:

  1. Edit the index.bs file or any of the sections\*.txt files.
  2. Build (as above). This will create a sections\*.include file for each *.txt file and then create the index.html.

When submitting pull requests, make sure you don't include any of the sections\*.include files in your changelist — they've all been added to the .gitignore file so that you don't include them accidentally. All changes should be made in the sections\*.txt files and index.bs.

Testing

Recommendations

If you enjoyed this spec, you might be interested in these other specs from the same publisher:

uievents's People

Contributors

afbarstow avatar ahulab avatar birtles avatar cvrebert avatar diagramatics avatar dima74 avatar dontcallmedom avatar dret avatar dtapuska avatar flackr avatar foolip avatar garykac avatar hayatoito avatar johanna-hub avatar jrandolf avatar jyasskin avatar marcoscaceres avatar mustaqahmed avatar navidz avatar plehegar avatar pyfisch avatar sahel-sh avatar samdutton avatar saschanaz avatar siusin avatar takayoshikochi avatar travisleithead avatar vapier avatar xfq avatar zcorpan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

uievents's Issues

Is CompositionEvent supposed to have .locale?

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28924

Olli Pettay 2015-07-07 17:24:39 UTC

It is not clear how CompositionEvent should behave per current draft.
Should it have .locale property which is then initialized for example using
the legacy initCompositionEvent?
And should the dictionary for ctor have locale too?

Some version of some spec (I'm getting lost with D3E, UIEvents and UIEventsExtensions) had .locale in KeyboardEvent.

Anyhow, since .locale is there for initCompositionEvent, I'll add it to the dictionary too in Gecko. Guess work here.

Comment 1 Olli Pettay 2015-07-07 17:27:53 UTC

Oh, CompositionEvent used to have readonly attribute DOMString? data, but now it is non-nullable. Why the backwards incompatible change?

Comment 2 Takayoshi Kochi 2015-07-08 08:14:06 UTC

I'm not following the D3E discussion lately, but ~2years ago when I
investigated this, only IE was implementing the .locale on Composition events.
It was hard to formulate the proper value for .locale, and I gave up
including it in IME API.

I'm not sure how popular the usage is, but I guess we should avoid
abandon .locale in the spec as it is poorly spec'ed and quite hard
or sometimes meanless to expose the value on some environment.

Note: You may wonder why .locale is filled for each event, even though
.locale should rarely change between events. I heard that the rationale
was for not leaking user's environment without user's consent - typing on
keyboard is considered an affirmative action that user let the user agent
(or the author of the content) know in which locale he/she is typing text.

Note2: the intention to include .locale in IME API was not only to
expose user's typing environment, but to change the locale so that
an author can force which language is expected to type in for
some form element etc. (i.e., .locale is writable). It might sound
useful, but quite hard to implement interoperably.

Specify the Event Loop integration for various non-deprecated events, incl. hit testing

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25927

Travis Leithead [MSFT] 2014-05-30 17:05:52 UTC

See discussion here: http://lists.w3.org/Archives/Public/www-dom/2014AprJun/0216.html

Comment 1 Anne 2014-05-30 17:26:08 UTC

See e.g. final paragraph of http://lists.w3.org/Archives/Public/www-tag/2014Apr/0035.html what level of detail I would expect. What events are dispatched as part of the same user action, how are their various fields initialized based on the data provided by the OS (e.g. data OS -> hit testing -> calculate offsets), etc.

Comment 2 Travis Leithead [MSFT] 2014-05-30 17:33:47 UTC

Thanks. I'll see about understanding how this all works in IE as a baseline, then think about how to write it down sensibly. :-)

Comment 3 Arthur Barstow 2015-03-21 15:12:06 UTC

Bulk move of all D3E bugs to the UI Events component.

Reference to createEvent("FocusEvent")

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28119

Ms2ger 2015-03-01 11:55:58 UTC

"To create an instance of the FocusEvent interface, use the DocumentEvent.createEvent("FocusEvent") method call. "

The DOM spec does not actually support a FocusEvent argument here.

Comment 1 Ms2ger 2015-03-01 12:14:30 UTC

(Similar sentences exist for other event interfaces too.)

Comment 2 Arthur Barstow 2015-03-21 15:11:59 UTC

Bulk move of all D3E bugs to the UI Events component.

"Introduced in this specification" in IDL not helpful

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28735

Philip Jägenstedt 2015-06-01 21:51:27 UTC

https://w3c.github.io/uievents/#interface-MouseEvent

Here buttons is annotated with "Introduced in this specification"

This isn't helpful when one copies the IDL into the browser engine source, as I'm trying to do in Blink. It would be nicer to just list the attributes in the sensible order (buttons after button) and to put this note in the definition of the attribute, as for https://w3c.github.io/uievents/#widl-MouseEvent-getModifierState

Comment 1 Boris Zbarsky 2015-06-02 00:27:17 UTC

Even more to the point, unless this is the only definition of MouseEvent, this should probably be a partial interface....

Comment 2 Philip Jägenstedt 2015-06-02 07:40:24 UTC

This seems intended to be the main definition of MouseEvent.

Define Home key and Back key of Android smartphone

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21136

Masayuki Nakano 2013-02-27 03:52:50 UTC

Usual Android smartphone has 3 buttons bottom of the device.

The left most key is back whose key code is KEYCODE_BACK.
The center key is home whose key code is KEYCODE_HOME.

Looks like D3E doesn't define the key for the back key. Should be 'Back' as UI?

The home key is 'Exit' according to the explanation in the D3E key name list. However, I'm not sure. If not, 'Top' as UI is good name? 'Home' is already defined for Home key on PC keyboard.

Comment 1 Travis Leithead [MSFT] 2013-06-19 00:31:01 UTC

Moving to UI Events until we define an extension doc for specific device keys like Android Smartphone.

Comment 2 Masayuki Nakano 2014-12-31 17:17:31 UTC

Perhaps, "HomeScreen" for the KEYCODE_HOME? (I.e., the home button)

MouseEvent should have DOMString pseudoElement property like TransitionEvent

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22569

Elliott Sprehn 2013-07-03 23:53:52 UTC

Just like with TransitionEvent we should support pseudoElement on MouseEvent so when you click a ::before or ::after or ::backdrop the click event you get back tells you which pseudo element was clicked.

See: http://www.w3.org/TR/css3-transitions/

This is important for since it's quite common to want to dismiss the dialog when the user clicks the ::backdrop but right now you can't know that without getting the bounding client rects of the and then looking to see if the hit was inside there.

Comment 1 Olli Pettay 2013-07-04 09:02:57 UTC

Sounds like a bug in design if it is expected that event handling
explicitly needs to deal with pseudoElements all the time.

Comment 2 Matt Falkenhagen 2013-07-04 12:29:31 UTC

(In reply to comment #1)

Sounds like a bug in design if it is expected that event handling
explicitly needs to deal with pseudoElements all the time.

If it helps, this is just for modal which has a ::backdrop for
optionally graying out the screen underneath it. It makes sense to me
that you can handle events on ::backdrop, so you can dismiss the dialog
or make it bounce for attention. But maybe there is a better design.

Comment 3 Elliott Sprehn 2013-07-11 17:31:33 UTC

It seems totally reasonable to want to know if someone clicked the element or the ::before or ::after. Right now if I position the ::before absolutely somewhere else on the page I can't easily tell (without triggering an unnecessary layout by calling getBoundingClientRects()) if the click was in the ::before or inside element itself.

Comment 4 Travis Leithead [MSFT] 2013-07-11 18:14:40 UTC

This is a great suggestion. As it is a new feature request, I'm moving it to the node for future DOM 3 Events features: UI Events.

scroll should be a simple Event not a UIEvent

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28890

Rick Byers 2015-07-03 13:42:59 UTC

AFAIK all browsers implement it just as 'Event'. Gary says the WG planned to change the spec (http://crbug.com/503280#c1). This sounds like a good idea to me (makes my life easier: https://github.com/RByers/InputDevice/issues/5).

I could imagine there might be reasons to want to add to the scroll event in the future (eg. I've wanted velocity and maybe other properties on it), but we can cross that bridge if/when we come to it.

Mechanism to differentiate pointer input from multiple users/devices missing

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22891

Sangwhan Moon 2013-08-06 14:32:03 UTC

The standard currently does not provide a reliable way to determine multiple users inputting with multiple devices, as all the pointers will be generated in one flat queue with no mechanism to differentiate the source.

As a directly affected use case, gaming consoles will not be able to make use of pointer events without proprietary hacks or extensions.

Comment 1 Arthur Barstow 2013-09-10 16:58:45 UTC

The Pointer Events WG discussed this bug on 10-Sep-2013 and the minutes from that discussion are http://www.w3.org/2013/09/10-pointerevents-minutes.html#item05.

Comment 2 Arthur Barstow 2013-09-11 11:08:25 UTC

Moving this to WebApps' UI Events spec per resolution of the Pointer Events WG (PEWG) on 10-Sep-2013 (URI below).

SeeAlso: PEWG's UCs and requirements doc http://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements

Define mobile phone related keys

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21121

Masayuki Nakano 2013-02-26 07:55:53 UTC

There are some telephone related keys which are not defined in D3E:

GTK Qt Android
GDK_Phone Qt::Key_Phone
Qt::Key_Call KEYCODE_CALL
Qt::Key_CameraFocus KEYCODE_FOCUS
Qt::Key_Hangup KEYCODE_ENDCALL
Qt::Key_ToggleCallHangup
Qt::Key_VoiceDial
Qt::Key_LastNumberRedial
KEYCODE_HEADSETHOOK
KEYCODE_MANNER_MODE
KEYCODE_CONTACTS

Comment 1 Masayuki Nakano 2013-02-27 02:30:58 UTC

My suggestions are:

'LaunchPhone' as General or 'Phone' as Device
'PhoneCall' as Phone
'CameraFocusAdjust' as Device
'PhoneHangup' as Phone
'TogglePhoneCallHangup' as Phone
'LaunchVoiceDial' as General or Phone
'HeadsettHook' as Phone or Device
'ToggleMannerMode' as Phone or Device
'LaunchAddressBook' as General

Comment 2 Masayuki Nakano 2013-05-08 12:36:00 UTC

http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_MUTE

Android's KEYCODE_MUTE is a mute key for microphone.

It should be 'MicMute' as Device?

Proposal key names for Android

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21083

Masayuki Nakano 2013-02-22 09:23:52 UTC

I'm trying to implement KeyboardEvent.key value for non-printable keys on Android. Then, following native keys cannot be mapped to the key names in the list (http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#key-values-list):

  • KEYCODE_SOFT_LEFT: I have no idea.
  • KEYCODE_SOFT_RIGHT: I have no idea.
  • KEYCODE_HOME: Perhaps, 'Exit'? The key name is 'Home' but it exits active application and moves to home screen.
  • KEYCODE_BACK: 'Back' as UI key? It's not only used for browser's 'back'.
  • KEYCODE_CALL: 'PhoneCall' as Device key?
  • KEYCODE_ENDCALL: 'PhoneEndCall' as Device key?
  • KEYCODE_SYM: 'Symbol' as Modifier key? The Android document says this is a modifier, but D3E defines only 'SymbolLock'.
  • KEYCODE_NUM: I'm not sure what's this key.
  • KEYCODE_NOTIFICATION: I'm not sure what's this key too.
  • KEYCODE_PICTSYMBOLS: 'PictureSymbolMode' as IME key?
  • KEYCODE_MEDIA_CLOSE: 'Close' as Device key? It closes opened tray by 'Eject'. Then, 'Eject' should be separated as 'Eject' and 'EjectClose'?
  • KEYCODE_ZOOM_IN: 'ZoomIn' as UI?
  • KEYCODE_ZOOM_OUT: 'ZoomOut' as UI?
  • KEYCODE_TV: Perhaps, 'Live'? But I think that 'TV' as Media key is better.
  • KEYCODE_DVR: 'DVR' or 'VideoRecorder' as Media key?
  • KEYCODE_TV_POWER: 'TVPower' as Media key?
  • KEYCODE_TV_INPUT: 'TVSelectInput' as Media key?
  • KEYCODE_STB_POWER: 'STBPower' as Media key?
  • KEYCODE_STB_INPUT: 'STBSelectInput' as Media key?
  • KEYCODE_AVR_POWER: 'AVReceiverPower' as Media key?
  • KEYCODE_AVR_INPUT: 'AVReceiverSelectInput' as Media key?
  • KEYCODE_LANGUAGE_SWITCH: 'ToggleLanguage' or 'SwitchLanguage' as IME key?
  • KEYCODE_MANNER_MODE: 'ToggleMannerMode', 'SwitchMannerMode' or just 'MannerMode' as Device key?
  • KEYCODE_3D_MODE: 'Toggle3DMode' as Media key?
  • KEYCODE_CONTACTS: 'LaunchAddressBook' as General key?
  • KEYCODE_CALENDAR: 'LaunchCalendar' as General key?
  • KEYCODE_MUSIC: 'LaunchMusicPlayer' as General key?
  • KEYCODE_CALCULATOR: 'LaunchCalculator' as General key?
  • KEYCODE_ZENKAKU_HANKAKU: 'ToggleWidth' as IME key? Both 'FullWidth' and 'HalfWidth' are not useful for this.
  • KEYCODE_KATAKANA_HIRAGANA: 'ToggleKatakanaHiragana' as IME key? 'Katakana' and 'Hiragana' key are not useful for this.

And for game pad:

KEYCODE_BUTTON_A:
KEYCODE_BUTTON_B:
KEYCODE_BUTTON_C:
KEYCODE_BUTTON_X:
KEYCODE_BUTTON_Y:
KEYCODE_BUTTON_Z:
KEYCODE_BUTTON_L1:
KEYCODE_BUTTON_R1:
KEYCODE_BUTTON_L2:
KEYCODE_BUTTON_R2:
KEYCODE_THUMBL:
KEYCODE_THUMBR:
KEYCODE_BUTTON_START:
KEYCODE_BUTTON_SELECT:
KEYCODE_BUTTON_MODE:
KEYCODE_BUTTON_1:
KEYCODE_BUTTON_2:
KEYCODE_BUTTON_3:
KEYCODE_BUTTON_4:
KEYCODE_BUTTON_5:
KEYCODE_BUTTON_6:
KEYCODE_BUTTON_7:
KEYCODE_BUTTON_8:
KEYCODE_BUTTON_9:
KEYCODE_BUTTON_10:
KEYCODE_BUTTON_11:
KEYCODE_BUTTON_12:
KEYCODE_BUTTON_13:
KEYCODE_BUTTON_14:
KEYCODE_BUTTON_15:
KEYCODE_BUTTON_16:

'GamePadButtonA'..., 'GamePadThumbLeft', 'GamePadThumbRight', 'GamePadButton1"?

Comment 1 Masayuki Nakano 2013-02-22 09:24:37 UTC

Oops, the document of Android is here:
http://developer.android.com/reference/android/view/KeyEvent.html

Comment 2 Masayuki Nakano 2013-02-23 02:21:53 UTC

(In reply to comment #0)

KEYCODE_THUMBL:
KEYCODE_THUMBR:

They are:

KEYCODE_BUTTON_THUMBL:
KEYCODE_BUTTON_THUMBR:

Then, the names are:

'GamePadButtonThumbLeft', 'GamePadButtonThumbRight'?

Comment 3 Gary Kacmarcik 2013-02-26 05:41:45 UTC

I'm not sure it makes sense to maps these values to 'key' or 'char'.

The documentation states:
"Key codes typically correspond one-to-one with individual keys on an input device. Many keys and key combinations serve quite different functions on different input devices so care must be taken when interpreting them. Always use the KeyCharacterMap associated with the input device when mapping keys to characters."

This sounds more like a 'code' value and some of the names (like KEYCODE_ZENKAKU_HANKAKU and KEYCODE_KATAKANA_HIRAGANA) are consistent with this interpretation.

To get a key/char, it looks like you'd need to pass the code value to the KeyCharacterMap (http://developer.android.com/reference/android/view/KeyCharacterMap.html) rather than using these codes directly.

Comment 4 Masayuki Nakano 2013-02-26 05:59:17 UTC

Gary:

I'm talking about non-printable keys. Looks like getDisplayLabel() returns null if the key is non-printable.
http://developer.android.com/reference/android/view/KeyCharacterMap.html#getDisplayLabel%28int%29

Comment 5 Masayuki Nakano 2013-02-27 02:36:57 UTC

I separated following key definition to bug 21121:

  • KEYCODE_CALL: 'PhoneCall' as Device key?
  • KEYCODE_* KEYCODE_MANNER_MODE: 'ToggleMannerMode', 'SwitchMannerMode' or just 'MannerMode' as Device key?
  • ENDCALL: 'PhoneEndCall' as Device key?
  • KEYCODE_CONTACTS: 'LaunchAddressBook' as General key?

I separated following key definition to bug 21120:

  • KEYCODE_TV: Perhaps, 'Live'? But I think that 'TV' as Media key is better.
  • KEYCODE_DVR: 'DVR' or 'VideoRecorder' as Media key?
  • KEYCODE_TV_POWER: 'TVPower' as Media key?
  • KEYCODE_TV_INPUT: 'TVSelectInput' as Media key?
  • KEYCODE_STB_POWER: 'STBPower' as Media key?
  • KEYCODE_STB_INPUT: 'STBSelectInput' as Media key?
  • KEYCODE_AVR_POWER: 'AVReceiverPower' as Media key?
  • KEYCODE_AVR_INPUT: 'AVReceiverSelectInput' as Media key?
  • KEYCODE_3D_MODE: 'Toggle3DMode' as Media key?

I separated following key definition to bug 21119:

  • KEYCODE_ZOOM_IN: 'ZoomIn' as UI?

  • KEYCODE_ZOOM_OUT: 'ZoomOut' as UI?

    Comment 6 Masayuki Nakano 2013-02-27 03:57:50 UTC

    I separated following key definition to bug 21136:

  • KEYCODE_HOME: Perhaps, 'Exit'? The key name is 'Home' but it exits active application and moves to home screen.

  • KEYCODE_BACK: 'Back' as UI key? It's not only used for browser's 'back'.

I separated following key definition to bug 21135:

  • KEYCODE_SYM: 'Symbol' as Modifier key? The Android document says this is a modifier, but D3E defines only 'SymbolLock'.

I separated following key definition to bug 21134:

  • KEYCODE_CONTACTS: 'LaunchAddressBook' as General key?
  • KEYCODE_MUSIC: 'LaunchMusicPlayer' as General key?
  • KEYCODE_CALCULATOR: 'LaunchCalculator' as General key?
Comment 7 Masayuki Nakano 2013-02-27 06:13:08 UTC

I separated the game pad related keys definition to bug 21137.

Comment 8 Masayuki Nakano 2013-02-27 06:47:59 UTC

I filed bug 21139 for

  • KEYCODE_ZENKAKU_HANKAKU: 'ToggleWidth' as IME key? Both 'FullWidth' and 'HalfWidth' are not useful for this.
  • KEYCODE_KATAKANA_HIRAGANA: 'ToggleKatakanaHiragana' as IME key? 'Katakana' and 'Hiragana' key are not useful for this.

And I filed bug 21083 for

  • KEYCODE_PICTSYMBOLS: 'PictureSymbolMode' as IME key?
  • KEYCODE_LANGUAGE_SWITCH: 'ToggleLanguage' or 'SwitchLanguage' as IME key?

Then, remaining issues here are:

  • KEYCODE_SOFT_LEFT: I have no idea.
  • KEYCODE_SOFT_RIGHT: I have no idea.
  • KEYCODE_NUM: I'm not sure what's this key.
  • KEYCODE_NOTIFICATION: I'm not sure what's this key too.

beforeInput should also be triggered when no "character value" is produced

The spec currently says that the beforeInput event is "only for keys which produce a character value" [1]. I spoke to @ojanvafai at the CSSWG meeting about this, and he said it was an error in that document, because they probably exchanged the "textinput" event with the "beforeinput" event and then left that text in there by mistake.

The way we have decided to use the beforeInput event at the Editing Taskforce F2F is for it to be triggered at all user-initiated editor events, including undo/redo, bold/italics, delete, etc. . This means that the description "(only for keys which produce a character value)" should be removed.

See also w3c/editing#87

[1] https://w3c.github.io/uievents/#h-events-keyboard-event-order

Need way to determine what keys are supported on device.

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19771

Glenn Adams 2012-10-30 06:43:02 UTC

On devices that use RCs (remote controls), it is often the case that the set of supported keys vary. For example, one RC might have red, green, blue buttons, while another might have red, green, blue, yellow. There is also much variation in supported keys for media related functions and other device specific extensions.

At present DOM-3 Events does not specify that any particular physical key must be supported on a device. But rather, simply defines which key values are to be used when a key is present. [Though even this is ambiguous since if some physical key is present, there is nothing in DOM-3 Events which mandates a specific key (string) value be used.]

In order to address this, I suggest defining an appropriate API in DOM-3 Events, e.g.,

partial interface Navigator {
   DOMString? getKeyLabel(DOMString keyString, optional DOMString locale);
}

The method getKeyLabel() returns a non-empty string that denotes a device dependent label for a key that generates keyString, or, if no key generates keyString, then returns null. If locale is specified and non-empty, and if a locale specific label is available, then it should be returned instead of a default label.

The returned label should be suitable for presentation to the end-user in a user interface in order to indicate to the user the label of the key found on the (physical or virtual) key.

In all cases, either a non-empty string or null shall be returned.

It might also be desirable to provide an additional method, such as:

partial interface Navigator {
   DOMString[] getKeyStrings();
}

which returns all key strings supported by the device [that could be used as an argument when calling getKeyLabel()].

This latter would be useful for making effective use of keys for which no standard key string has yet been published.

Comment 1 Hallvord R. M. Steen 2012-11-02 08:28:57 UTC

The implementation should have some protection against fingerprinting, for privacy reasons.

Comment 2 Gary Kacmarcik 2013-05-17 16:42:19 UTC

We're trying to do something similar with queryKeyCaps in UI Events.

Since this certainly won't be part of D3E at this point, I'm changing the component to "UI Events" so we can consider it for that spec.

Distinguish between Space and Enter in Forms

Original title: Most user agents (Chrome, Firefox) seem to distinguish between space and enter. Enter submits the form, even for radio buttons, space selects the checkbox

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27333

[email protected] 2014-11-15 06:16:06 UTC

Specification: https://html.spec.whatwg.org/multipage/forms.html
Multipage: https://html.spec.whatwg.org/multipage/#file-upload-state-(type=file)
Complete: https://html.spec.whatwg.org/#file-upload-state-(type=file)
Referrer: https://html.spec.whatwg.org/multipage/interaction.html

Comment:
Most user agents (Chrome, Firefox) seem to distinguish between space and
enter. Enter submits the form, even for radio buttons, space selects the
checkbox.

Should the spec be updated for this?

(Additionally, it's not very clear in the spec the different ways in which an
element can be activated)

Posted from: 103.21.125.76
User agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0

Comment 1 Manish Goregaokar 2014-11-15 06:17:35 UTC

(Submitter here)

The correct spec link is https://html.spec.whatwg.org/multipage/forms.html#radio-button-state-%28type=radio%29, though there are similar issues throughout the spec.

Comment 2 Ian 'Hixie' Hickson 2014-11-19 22:09:35 UTC

This is mostly up to the browser. That it is possible for "enter" to submit the form is described here:

https://html.spec.whatwg.org/multipage/#implicit-submission

...but I don't know what else we can say. We can't say "space selects, enter submits", because what if the browser doesn't have a keyboard? Or has two "enter" keys? Or wants space bar to page down, and "x" to select?

Comment 3 Manish Goregaokar 2014-11-20 03:52:13 UTC

So we only consider hitting theenter key as activation? This seems to say differently:

https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-type-keydown

If the key is the 'Enter' or ' ' key and the current focus is on a state-changing element, the default action MUST be to dispatch a click event, and a DOMActivate event if that event type is supported by the user agent (refer to activation triggers and behavior for more details)

So this means that ' ' and 'Enter' should activate -- however as defined in the spec, activation means selection for a checkbox, which deviates from the spec.

I'm not even sure if 'Enter' should be triggering a click event.

Comment 4 Ian 'Hixie' Hickson 2014-11-20 18:17:48 UTC

That sounds like a problem with the DOM3 Events spec.

Comment 5 Manish Goregaokar 2014-11-20 18:22:48 UTC

Moving over to DOM3 as per Hixie's comment

Comment 6 Arthur Barstow 2015-03-21 15:11:56 UTC

Bulk move of all D3E bugs to the UI Events component.

Mouse coordinates represented in CSS pixels do not account for retina displays with window.devicePixelRatio > 1

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28029

Jukka Jylänki 2015-02-14 18:52:55 UTC

In e.g. the MouseEvent structure, the mouse xy coordinates are stored with the data type 'long', see here: http://www.w3.org/TR/DOM-Level-3-Events/#interface-MouseEvent .

There does not seem to be a clear documentation on how these coordinates relate to the value of window.devicePixelRatio (or I'm missing it). Looking at current implementation in Firefox, Safari and Chrome, the coordinate system that the fields clientX, clientY, screenX and screenY are specified in are the hardware-independent "CSS pixel" units meaning that they do not directly correspond to physical pixels on the display.

That is, testing on a Macbook Pro with 2880x1800 retina display, in each Firefox, Chrome and Safari, window.devicePixelRatio gives 2, and running this page

http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_event_mouse_screenxy

the extents of screenX and screenY range between (0, 0) and (1440, 900). In order to get the exact pixel coordinate where the mouse lies in, one must multiply the screenX and screenY parameters by window.devicePixelRatio, i.e. by a factor of 2 in this case.

However, since screenX and screenY (and all the other fields that represent mouse coordinates are of type 'long', this means that after multiplying, in both X and Y directions every second pixel is missed and only 25% of all pixels on the display are addressable by screenX and screenY.

4K resolutions are coming in fast, and I expect that browsers might use a window.devicePixelRatio of 4 on those displays. This would mean that only 1/16th or 6.25% of all hardware pixels would be addressable by the mouse event structure!

It looks like all the mouse coordinates throughout all events in the DOM specs should be passed as type 'double' instead of 'long' in places where the coordinates are represented in CSS pixels so that each hardware pixel will be addressable.

I wonder if I'm missing something here, and if this issue can be (has been?) resolved in some other way?

Comment 1 Boris Zbarsky 2015-02-14 19:26:10 UTC

We should probably add accessors with new names that return the actual coordinate as a double. Changing the behavior of the existing names is unlikely to be web-compatible.

Comment 2 Boris Gjenero 2015-02-15 05:19:51 UTC

Note that movementX and movementY values described in the pointer lock API are also affected: https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#extensions-to-the-mouseevent-interface

There is the same loss of precision as with position plus there is also the possibility that slow movement gets rounded to zero and ignored. It may be possible to slowly move the mouse as far as you want without causing any movement to be reported. I can reproduce this in Firefox 35 when using increased layout.css.devPixelsPerPx. A browser could work around this by accumulating sub-pixel motion, but floating point values are a better solution.

Comment 3 Anne 2015-02-15 08:43:30 UTC

Note that the new iMac with a 5K screen simply uses a ratio of 2 so it's not that big of deal yet, but we should probably do something now so it's deployed and ready a couple years from now.

Comment 4 Jukka Jylänki 2015-02-15 10:06:25 UTC

I would be very cautious to state that this is not currently a big deal, since already now only one quarter of the pixels on the screen are representable by the DOM events on high DPI displays, and Macbook Pro retina displays came out already in 2012.

I believe this issue also exists for all touch events http://www.w3.org/TR/touch-events/#touch-interface , and currently the majority of mobile devices out there have a window.devicePixelRatio greater than one. For example, Google Nexus 4 has a devicePixelRatio of 2, and iPhone 6 Plus has a devicePixelRatio of 3.

Also like Boris Gjenero mentions, this issue causes precision and stuttering to pointer lock and relative mouse movement.

In my opinion, this is definitely a critical P1 bug. Most web APIs do not properly handle high DPI, and the invention of hardware-independent pixels was not done with a good understanding or design of its wide-spanning implications on the different web APIs. This is a surface area of bugs that keeps popping up in different places, here's a small example of recent issues to illustrate:

KhronosGroup/WebGL#587
https://www.khronos.org/webgl/public-mailing-list/archives/1406/msg00019.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1021547
https://bugzilla.mozilla.org/show_bug.cgi?id=1024493

And the common underlying issue in all of these is that the web APIs were not designed to account for window.devicePixelRatio > 1.

My point is that everything is already broken now, and not just in a few years. I would like to plea that this issue is taken seriously in W3, and even further, I would like to see that non-high DPI APIs would get aggressively documented as being broken and deprecated in the future.

Comment 5 Simon Pieters 2015-02-16 19:05:28 UTC

http://dev.w3.org/csswg/cssom-view/#extensions-to-the-mouseevent-interface specifies MouseEvent's members as double. This has been shipping in IE without opt-in since IE10. Blink plans to implement it also, see http://crbug.com/456625

Also see this thread: https://lists.w3.org/Archives/Public/www-style/2015Feb/thread.html#msg193

Comment 6 Travis Leithead [MSFT] 2015-02-16 20:05:36 UTC

(In reply to Simon Pieters from comment #5)

http://dev.w3.org/csswg/cssom-view/#extensions-to-the-mouseevent-interface
specifies MouseEvent's members as double. This has been shipping in IE
without opt-in since IE10. Blink plans to implement it also, see
http://crbug.com/456625

Also see this thread:
https://lists.w3.org/Archives/Public/www-style/2015Feb/thread.html#msg193

Note, we just reverted this behavior in our latest IE builds due to compat issues (with web content that works on Chrome). Specifically, for MouseEvent instances, IE will no longer return coordinate members as double. (We still do for Touch/Pointer though.)

Comment 7 Simon Pieters 2015-02-17 09:44:52 UTC

Thanks Travis. Do you have information on which URLs broke? It is sad that MouseEvent has not been prioritized for Blink before you had to revert it.

Comment 8 Travis Leithead [MSFT] 2015-03-12 22:57:42 UTC

(In reply to Simon Pieters from comment #7)

Thanks Travis. Do you have information on which URLs broke? It is sad that
MouseEvent has not been prioritized for Blink before you had to revert it.

Looking back through the checkins... looks like:

Comment 9 Simon Pieters 2015-03-16 11:18:30 UTC

OK, that's the same as https://www.w3.org/Bugs/Public/show_bug.cgi?id=24159#c2

Do I understand correctly that there were no other sites reported broken? Would you consider implementing it again if Blink implemented it?

Comment 10 Arthur Barstow 2015-03-21 15:11:54 UTC

Bulk move of all D3E bugs to the UI Events component.

DOM Level 3 KeyboardEvent key Values specification does not include core key values

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27825

Patrick Ladd 2015-01-13 23:48:47 UTC

The DOM Level 3 Events specification, https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#keys-keyvalues, (section 6.3) second paragraph states, "The list of valid key values is defined in the DOM Level 3 KeyboardEvent key Values Specification [DOM3 key Values]." However, the DOM Level 3 KeyboardEvent key Values specification, http://www.w3.org/TR/DOM-Level-3-Events-key/, does not include tables for core key values such as numerical keys (0-9), alphabetic keys (a-z), or symbol keys. The reader must, for instance, look at example 21 in the DOM Level 3 Events specification to deduce that pressing the 2 key causes the value of '2' to be placed in the KeyboardEvent.key field and then extrapolate that to other numerical keys.

Comment 1 Arthur Barstow 2015-03-21 15:11:51 UTC

Bulk move of all D3E bugs to the UI Events component.

How do web apps distinguish if a keydown event causes text input?

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23907

Masayuki Nakano 2013-11-25 08:45:34 UTC

Even there is beforeinput event, web applications may want to distinguish whether a keydown event causes text input or not at keydown event handler.

For example, if web apps wants to implement text editor and their own shortcut keys, if a key event will cause text input, it shouldn't be handled as shortcut key at keydown event.

E.g., Ctrl+Shift+2 of Persian keyboard layout causes inputting ZWNJ.
https://bugzilla.mozilla.org/show_bug.cgi?id=414130

So, in such case, text input may be preferred rather than kicking shortcut.

I'd like to suggest a new attribute KeyboardEvent.inputText as bool.

Comment 1 Travis Leithead [MSFT] 2013-12-04 01:49:09 UTC

Moving to UIEvents component with permission from opener. We will not address this as part of finishing DOM3 Events.

Need 'Unspecified' value for KeyboardEvent.code

The current spec doesn't define an 'Unspecified' value that can be used when the code value cannot be determined.

Having a separate value is important to be able to distinguish between 'not implemented' and 'implemented, but unable to determine code'.

Currently, we define 'Unspecified' for 'key', but don't have the equivalent text for 'code'.

Partial interfaces must not inherit

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27721

Rainer Schuster 2015-01-01 13:19:53 UTC

Instead of

partial interface KeyboardEvent : UIEvent {

the following should be used

partial interface KeyboardEvent {

because partial interfaces are not allowed to specify inheritance.

Comment 1 Olli Pettay 2015-01-01 15:43:04 UTC

Well KeyboardEvent should just inherit UIEvent, no need for 'partial' there.

Comment 2 Rainer Schuster 2015-01-03 16:47:55 UTC

(In reply to Olli Pettay from comment #1)

Well KeyboardEvent should just inherit UIEvent, no need for 'partial' there.

Note that KeyboardEvent is also specified in http://www.w3.org/TR/DOM-Level-3-Events/#interface-KeyboardEvent
so IMHO it would make sense to just cut the inheritance " : UIEvent". BTW no information would be lost since the inheritance is already specified to inherit from UIEvent in the DOM Level 3 Events specification.

Define TV or A/V remote controller's keys

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21120

Masayuki Nakano 2013-02-26 07:37:21 UTC

I found some keys for TV or A/V remote controller's key which are not defined in D3E.

GTK Qt Android
GDK_Switch_VT_1
GDK_Switch_VT_2
GDK_Switch_VT_3
GDK_Switch_VT_4
GDK_Switch_VT_5
GDK_Switch_VT_6
GDK_Switch_VT_7
GDK_Switch_VT_8
GDK_Switch_VT_9
GDK_Switch_VT_10
GDK_Switch_VT_11
GDK_Switch_VT_12
GDK_CycleAngle
GDK_AudioCycleTrack Qt::Key_AudioCycleTrack
GDK_AudioRepeat Qt::Key_AudioRepeat
GDK_FrameBack
GDK_FrameForward
GDK_Time Qt::Key_Time
GDK_View Qt::Key_View
GDK_TopMenu Qt::Key_TopMenu
ContrastAdjust Qt::Key_ContrastAdjust
Qt::Key_BassBoost
Qt::Key_TrebleUp
Qt::Key_TrebleDown
Qt::Key_CD
Qt::Key_Video KEYCODE_DVR
KEYCODE_TV
KEYCODE_MEDIA_CLOSE
KEYCODE_TV_POWER
KEYCODE_TV_INPUT
KEYCODE_STB_POWER
KEYCODE_STB_INPUT
KEYCODE_AVR_POWER
KEYCODE_AVR_INPUT
KEYCODE_3D_MODE

Comment 1 Masayuki Nakano 2013-02-27 02:55:36 UTC

My suggestions are:

'Channel1' as Media
'Channel2' as Media
'Channel3' as Media
'Channel4' as Media
'Channel5' as Media
'Channel6' as Media
'Channel7' as Media
'Channel8' as Media
'Channel9' as Media
'Channel10' as Media
'Channel11' as Media
'Channel12' as Media
'SwitchAngle' as Media
'MediaRepeatTrack' as Media (I'm not sure the actual purpose of this key)
'MediaRepeat' as Media
'FrameBack' as Media
'FrameForward' as Media
'TimeSearch' as Media (I'm not sure the actual purpose of this key)
I have no idea for view key since I'm not sure the actual purpose of it.
'MediaTopMenu' as Media
'ContrastAdjust' as Media
'AudioBassBoost' as Media
'AudioTrebleUp' as Media
'AudioTrebleDown' as Media
'CD' as Media
'Video' as Media
'TV' as Media
'TrayClose' as Device
'TVPower' as Media or Device
'TVSelectInput' as Media or Device
'STBPower' as Media or Device
'STBSelectInput' as Media or Device
'AVReceiverPower' as Media or Device
'AVReceiverSelectInput' as Media or Device
'Toggle3DMode' as Media

Comment 2 Masayuki Nakano 2013-02-27 08:30:37 UTC

On Windows, we can also dispatch key events for:

APPCOMMAND_BASS_BOOST (same as Qt::Key_BassBoost) 'AudioBassBoost'
APPCOMMAND_MIC_ON_OFF_TOGGLE 'MicToggle'
APPCOMMAND_MICROPHONE_VOLUME_DOWN 'MicVolumeDown'
APPCOMMAND_MICROPHONE_VOLUME_MUTE 'MicVolumeMute'
APPCOMMAND_MICROPHONE_VOLUME_UP 'MicVolumeUp'
APPCOMMAND_TREBLE_DOWN (same as Qt::Key_TrebleDown) 'AudioTrebleDown'
APPCOMMAND_TREBLE_UP (same as Qt::Key_TrebleUp) 'AudioTrebleUp'

Comment 3 Masayuki Nakano 2015-07-01 00:13:10 UTC

Additionally, we need to discuss the rules how to define key values of vendor or country specific buttons on remote control.

For example, Japanese TV remote controller typically has "地デジ" ( terrestrial digital broadcasting), "BS" (broadcast satellite broadcasting) and "CS" (communication satellite broadcasting) buttons which are to select type of broadcasting. However, some vendors may have "地デジ", "BS/CS" buttons. The "BS/CS" button toggles BS and CS broadcasting.

Another example, Japanese high-end TVs may have "Time Shift" related buttons. "Time Shift" feature is that TV records whole TV programs into external hard drive(s) and erase old records when the drive(s) doesn't have enough space to record new programs.

Comment 4 Masayuki Nakano 2015-07-01 00:15:26 UTC

I mean that like "Launch*", some generic rules are necessary for specific feature buttons.

Comment 5 Masayuki Nakano 2015-07-06 07:38:46 UTC

Android defined some new keycode values:

KEYCODE_11
KEYCODE_12 // no _10, but 0 - 9 were defined as numeric keys in PC keyboard :-(
KEYCODE_LAST_CHANNEL
KEYCODE_MEDIA_TOP_MENU
KEYCODE_PAIRING // for BT, remote controller, gamepad
KEYCODE_TV_ANTENNA_CABLE
KEYCODE_TV_AUDIO_DESCRIPTION
KEYCODE_TV_AUDIO_DESCRIPTION_MIX_DOWN
KEYCODE_TV_AUDIO_DESCRIPTION_MIX_UP
KEYCODE_TV_CONTENTS_MENU
KEYCODE_TV_DATA_SERVICE
KEYCODE_TV_INPUT_COMPONENT_1
KEYCODE_TV_INPUT_COMPONENT_2
KEYCODE_TV_INPUT_COMPOSITE_1
KEYCODE_TV_INPUT_COMPOSITE_2
KEYCODE_TV_INPUT_HDMI_1
KEYCODE_TV_INPUT_HDMI_2
KEYCODE_TV_INPUT_HDMI_3
KEYCODE_TV_INPUT_HDMI_4
KEYCODE_TV_INPUT_VGA_1
KEYCODE_TV_MEDIA_CONTEXT_MENU
KEYCODE_TV_NETWORK
KEYCODE_TV_NUMBER_ENTRY
KEYCODE_TV_RADIO_SERVICE
KEYCODE_TV_SATELLITE
KEYCODE_TV_SATELLITE_BS
KEYCODE_TV_SATELLITE_CS
KEYCODE_TV_SATELLITE_SERVICE
KEYCODE_TV_TELETEXT
KEYCODE_TV_TERRESTRIAL_ANALOG
KEYCODE_TV_TERRESTRIAL_DIGITAL
KEYCODE_TV_TIMER_PROGRAMMING
KEYCODE_TV_ZOOM_MODE

For synthetic activation, should the original event still be dispatched?

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27337

Manish Goregaokar 2014-11-16 02:15:53 UTC

"If the instance of the activation trigger is not an event of event type click (that is, when it does not result from a user's activation of a button or link using a mouse or equivalent pointing device), the implementation MUST synthesize and dispatch an event of event type click as one of the default actions of that activation trigger. The value of the Event.target MUST be set to the event target (normally, the currently focused element), and the event MUST simulate a left click (i.e., the MouseEvent.button attribute value MUST be 0, and the MouseEvent.buttons attribute value MUST be 1). Other context information of such a simulated click event is implementation dependent, but for historical purposes, the interface for the click event MUST be the MouseEvent interface, regardless of the actual device used to activate the element. Preventing the default action of the activation trigger, such as with the Event.preventDefault(), MUST stop the initiation of the activation behavior."

This isn't clear as to what we're supposed to do with the original event.

For example, if the user hits enter on a form control, should we also dispatch keyboard events for the enter key, or only a mouse click event?

Comment 1 Anne 2014-11-17 13:05:12 UTC

Since it's triggered as the default action of the trigger (which is kind of bogus phrasing), the original event is assumed to be dispatched as well. But currently the way this text is written is indeed rather messy.

Comment 2 Manish Goregaokar 2014-11-17 13:07:29 UTC

If so, is there any order to it?

A synthetic click consists of the following:

  • Pre activation dispatch
  • Click dispatch
  • Post activation dispatch

The key event it originated from also has keyup/keydown/keypress. How do these interleave?

Comment 3 Arthur Barstow 2015-03-21 15:12:07 UTC

Bulk move of all D3E bugs to the UI Events component.

[key] Needs more explicit explanation of "MediaSelect", "LaunchMediaPlayer" and "MediaApps"

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26141

Masayuki Nakano 2014-06-19 08:13:10 UTC

There are similar name keys:

'MediaSelect':
Select media.

'LaunchMediaPlayer':
The 'Media Player' key.

'MediaApps':
Show a list of media applications. (VK_APPS)

I understand them as:

'MediaSelect':
Opening media content (file) list. E.g., opening a folder which contains audio files, video files and/or image files.

'LaunchMediaPlayer':
Launching a player application which is not only for playing music. (For only music, there is 'LaunchMusicPlayer')

'MediaApps':
Show a list of media players, music players and/or image viwers.

Is this correct? Anyway, I'd like D3E-key spec should explain them more explicitly.

Comment 1 Gary Kacmarcik 2014-07-09 01:16:02 UTC

Per confcall discussion:

Remove MediaSelect (aka: LaunchMediaSelect)

Make a note in LaunchMediaPlayer that VK_LAUNCH_MEDIA_SELECT should use this value.

Comment 2 Masayuki Nakano 2014-07-09 01:21:32 UTC

Gary:

What's the motivation of there is separated "LaunchMusicPlayer"? Such key may launch multimedia player. And such difference shouldn't be important for web apps. So, merging "LaunchMusicPlayer" to "LaunchMediaPlayer" doesn't cause any problem. "music player" is a kind of "media player", I think.

Comment 3 Arthur Barstow 2015-03-21 15:12:00 UTC

Bulk move of all D3E bugs to the UI Events component.

When .getModifierState("OS") should be true?

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26218

Masayuki Nakano 2014-06-27 05:56:41 UTC

I believe that .getModifierState("OS") should be enabled only when "OS" key activates a modifier state, strictly.

However, this means that .getModifierState("OS") can be true only on Windows since "OSLeft" and "OSRight" are typically "Super" (or "Hyper") on Linux (I confirmed this mapping on Ubuntu 14.04 and Fedora 20).

Therefore, even if Linux users use PC keyboard, pressing "OSLeft" or "OSRight" key activates only "Super" modifier. I.e., .getModifierState("OS") is false on Linux and .getModifierState("Super") is true.

Firefox's Linux widget module owner concerned about this difference between Linux and Windows. If web application developers check .getModifierState("OS") and test it only on Windows, Linux users who are minority than Windows users cannot use such application like Windows users.

So, if we take a hack for this issue, it might be better to activate "OS" virtual modifier state on Linux when "Super" modifier is activated.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1023067

Comment 1 Masayuki Nakano 2014-07-01 07:15:51 UTC

Alternative idea is, "Super" and "Hyper" are typically used as system wide acceleration key. Therefore, Defining "SystemAccel" virtual modifier might be good. Then, we applications can ignore all key events which should NOT be consumed by applications (including web apps).

Comment 2 Gary Kacmarcik 2014-07-09 00:55:39 UTC

Proposed text for SystemAccel (per 8July2014 confcall)

For platforms that define a separate system level accelerator modifier key (eg: Windoes, Linux), the SystemAccel virtual modifier is set whenever the system level accelerator modifier is set. For platforms that do not have a separate system level accelerator key (eg: Mac) this virtual key is never set.

Comment 3 Masayuki Nakano 2014-07-09 01:27:34 UTC

SGTM. If D3E explains the use case, adding "This is useful for ignoring all key events when a system level accelerator modifier key is down."

Comment 4 Masayuki Nakano 2015-01-14 01:49:05 UTC

See also: http://www.w3.org/2014/07/09-webapps-minutes.html

Comment 5 Karl Tomlinson 2015-01-22 23:58:27 UTC

(In reply to Masayuki Nakano from comment #3)

SGTM. If D3E explains the use case, adding "This is useful for ignoring all
key events when a system level accelerator modifier key is down."

The system will usually prevent the key events from reaching the app if they
form a system-wide shortcut, so I don't think the app need check whether the
SystemAccel virtual modifier is set. That may mean there is no need for
a SystemAccel feature.

The only exception might be that the events around press and release of the
key activating and deactivating the modifier would be sent to the app.
However, the modifier would be present on either the press or release event,
not both, so the value here is still limited.

Comment 6 Karl Tomlinson 2015-01-23 00:01:32 UTC

My original concern was as follows: "Super" is a somewhat archaic name for a
key deriving from lisp keyboards [1]. These days it is most similar in use to
the Windows key, and probably would have been called "WIN" or "OS" or similar,
except that there didn't seem to be any need to add yet another name when
"Super" was already available. See [2] for a bit of an overview.

[1] http://home.comcast.net/~mmcm/kbd/SpaceCadet.html
[2] http://askubuntu.com/questions/19558/what-are-the-meta-super-and-hyper-keys

Similarly now, my feeling is that there is no need to add "Super" as there is
already "OS" available. (I don't really care about "Hyper". It's use would
be obscure.)

This is similar to the issue raised bug 22073 comment 0, only that "Super" is
more similar in functionality to "OS" than "Meta" is to "OS".

Comment 7 Masayuki Nakano 2015-01-28 01:30:24 UTC

(In reply to Karl Tomlinson from comment #5)

(In reply to Masayuki Nakano from comment #3)

SGTM. If D3E explains the use case, adding "This is useful for ignoring all
key events when a system level accelerator modifier key is down."

The system will usually prevent the key events from reaching the app if they
form a system-wide shortcut, so I don't think the app need check whether the
SystemAccel virtual modifier is set. That may mean there is no need for
a SystemAccel feature.

I don't think so. Such behavior isn't guaranteed on all Linux distributions. And also web apps may want to ignore key events while system accel modifier is active. For example, they may want to ignore such key events because of not inputting character.

(In reply to Karl Tomlinson from comment #6)

My original concern was as follows: "Super" is a somewhat archaic name for a
key deriving from lisp keyboards [1]. These days it is most similar in use
to
the Windows key, and probably would have been called "WIN" or "OS" or
similar,
except that there didn't seem to be any need to add yet another name when
"Super" was already available. See [2] for a bit of an overview.

[1] http://home.comcast.net/~mmcm/kbd/SpaceCadet.html
[2]
http://askubuntu.com/questions/19558/what-are-the-meta-super-and-hyper-keys

Similarly now, my feeling is that there is no need to add "Super" as there is
already "OS" available. (I don't really care about "Hyper". It's use would
be obscure.)

As far as I know, Hyper is also used by major distributions about a coupe of years ago. And Linux can map "Super" and "Hyper" different physical keys and different modifier flags.

I know it's not a usual settings but it's important to be possible. In such case, the mapping rule becomes impossible to map them.

Additionally, it's also not guaranteed that "Super" is used as "OS" key.

The most important merit of defining "Super" and "Hyper" as modifier key and defining "SystemAccel" is that this way never fails in any situations. This means that browsers keep the compatibility with the others (including its different OS version).

This is similar to the issue raised bug 22073 comment 0, only that "Super" is
more similar in functionality to "OS" than "Meta" is to "OS".

Yes, however, it means that we already have a problem, web apps need to check the OS for distinguishing the ideal behavior of "OS" and "Meta". So, adding "Super" and "Hyper" shouldn't cause new issue.

For web apps, "Accel" and "SystemAccel" are useful because they work independently from OS.

Comment 8 Arthur Barstow 2015-03-21 15:12:05 UTC

Bulk move of all D3E bugs to the UI Events component.

Clarify or change the use of "default action" to avoid confusion

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25844

Travis Leithead [MSFT] 2014-05-21 00:16:36 UTC

See: http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0519.html

the "default action" can be interpreted as something belonging to the event dispatch mechanism, when in reality it is not.

Comment 1 Travis Leithead [MSFT] 2014-05-21 00:17:05 UTC

See also: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230#c25

Comment 2 Travis Leithead [MSFT] 2014-05-30 18:58:24 UTC

From Anne van Kesteren:

On Fri, May 30, 2014 at 7:09 PM, Travis Leithead [email protected] wrote:

The event dispatch flow, handling of canceled flag, etc., is already
spec'd in DOM,

Well, yes. However, D3E talks a lot about "default action". Instead, it should talk about a particular action occurring (such as the user pressing a key) as part of a system-level task and that action should then cause a number of steps to happen:

  1. Gather enough data to create the appropriate event object.
  2. Dispatch the created event at a node that is also determined somehow.
  3. Check the event's canceled flag to see whether any "default action"
    can happen at this point.

Note that I left a ton of stuff vague here. We should try to be less vague in the specification.

Comment 3 Arthur Barstow 2015-03-21 15:12:04 UTC

Bulk move of all D3E bugs to the UI Events component.

Need to remove input/beforeinput event info from D3E and point to input event spec

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27827

Gary Kacmarcik 2015-01-14 01:29:41 UTC

Current (placeholder) spec is at: http://w3c.github.io/editing-explainer/input-events.html

We need to remove our input/beforeinput info and refer to this spec where appropriate.

Comment 1 Gary Kacmarcik 2015-01-26 04:33:48 UTC

Sections removed in https://dvcs.w3.org/hg/dom3events/rev/5bcdc56bc48c

Waiting for official spec link to fix up references to new spec.

Comment 2 Arthur Barstow 2015-03-21 15:11:59 UTC

Bulk move of all D3E bugs to the UI Events component.

Comment 3 Rick Byers 2015-07-23 17:40:22 UTC

Any update? It's really confusing for the UI Events spec to mention beforeinput/input and InputEvent but for the links to just go nowhere. Took me quite awhile to find https://w3c.github.io/editing/input-events.html.

Proposal for UIEvent "role" property

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25655

caitp 2014-05-10 23:13:45 UTC

A modest proposal:

We have UIEvents, which should typically represent user interactions. These interactions get described in more detail in subclasses, such as MouseEvent, where some representation of the clicked button and coordinates are provided.

What I propose is that events are optionally given a "role", designating their UI interaction.

For instance, if I swipe a touch screen, I might want to know that the requested user interaction is "scroll" throughout the page.

If I right-click on an element with a mouse configured for a typical right-handed person, I might want to know that the interaction's role should eventually open a context menu (and so, might have a role of "contextmenu")

If I left-click on an element with a mouse configured for a typical right-handed person, I might want to know that the interaction's role should typically be "navigation" or "selection" depending on the type of element being clicked.

I don't think this would be terribly difficult for vendors to implement, should be relatively easy to polyfill based on properties like current MouseEvent.button, or similar.

I also think this kind of information would be much easier to understand when developing a web application, rather than sorting out what type of interaction is expected based on numeric properties which behave differently across user agents.

So, I don't know for sure if this is a good design, but to me, it seems more useful than being merely provided something like multitouch finger counting or mouse buttons assigned to integers which are prone to change.

It could eventually be taken a step further to allow some nice declarative mechanism for changing the role a particular event should have, like I might say or something.

A couple of default interaction roles I would see being useful include:

  • navigate
  • submit
  • select / deselect (in terms of checking or unchecking a checkbox or select-multiple, or changing the selection of a select-one)
  • zoom
  • scroll
  • collapse
  • contextmenu
  • next / previous (in terms of tab-ordering)
  • drag / drop

There are bound to be useful ones that I've missed, but I think it's worth considering something like this for either DOM level 3 or DOM level 4, because it should allow people to worry about higher-level interactions, and worry less about low-level details when they don't need them.

For a simple example, suppose I am using the history API in my client-side application, and I have a catch-all click event handler which is used to handle navigation with the history API:

localFrame.addEventListener("click", function(event) {
  // ignore non-navigation roles
  if (event.role !== "navigate") return;

  // do the rest of the work
  if (resolveTemplateAndLoad(event.target.href))
    history.pushState(event.target.href, someData);
});

To take this a step further, it would be cool to be able to just listen for specific interaction roles, rather than listening for a specific event. This is because an interaction might take many different forms. I could scroll a page with a mousewheel or arrow keys, or by using the scrollbar. I could navigate to a new page by pressing enter or space on the currently focused item. So that form of API might look more like this:

// Suppose a hash fragment following an event name were said to mean "listen
// only to events filtered by the specific role" --- It might step on DOM
// event names currently, but namespaced events are usually being handled
// differently, so it would probably be fine. Just an example, though!
localFrame.addEventListener("#navigate", function(event) {
  var href = event.target.href;
  if (resolveTemplateAndLoad(href))
    history.pushState(href, someData);
});

Listening for events of a specific role might be harder to polyfill, but it would simplify a lot of client-side code, and I could see it being highly useful for app developers.

I'm interested in hearing what people think about this, it seems like something which could be fleshed out and implemented fairly easily. Maybe it doesn't belong in DOM level 3, but it would be really cool if we could agree on a way to do this nicely, and because of this, it would be great to hear if anyone is interested in something like that.

Comment 1 Masataka Yakura 2014-05-11 13:34:45 UTC

I think most of the use cases you describe are coverd by IndieUI Events.

IndieUI: Events 1.0
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html

Requirements for IndieUI: Events 1.0 and IndieUI: User Context 1.0
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-requirements.html

(In reply to caitp from comment #0)

A modest proposal:

We have UIEvents, which should typically represent user interactions. These
interactions get described in more detail in subclasses, such as MouseEvent,
where some representation of the clicked button and coordinates are provided.

What I propose is that events are optionally given a "role", designating
their UI interaction.

For instance, if I swipe a touch screen, I might want to know that the
requested user interaction is "scroll" throughout the page.

If I right-click on an element with a mouse configured for a typical
right-handed person, I might want to know that the interaction's role should
eventually open a context menu (and so, might have a role of "contextmenu")

If I left-click on an element with a mouse configured for a typical
right-handed person, I might want to know that the interaction's role should
typically be "navigation" or "selection" depending on the type of element
being clicked.

I don't think this would be terribly difficult for vendors to implement,
should be relatively easy to polyfill based on properties like current
MouseEvent.button, or similar.

I also think this kind of information would be much easier to understand
when developing a web application, rather than sorting out what type of
interaction is expected based on numeric properties which behave differently
across user agents.

So, I don't know for sure if this is a good design, but to me, it seems more
useful than being merely provided something like multitouch finger counting
or mouse buttons assigned to integers which are prone to change.

It could eventually be taken a step further to allow some nice declarative
mechanism for changing the role a particular event should have, like I might
say or something.

A couple of default interaction roles I would see being useful include:

  • navigate
  • submit
  • select / deselect (in terms of checking or unchecking a checkbox or
    select-multiple, or changing the selection of a select-one)
  • zoom
  • scroll
  • collapse
  • contextmenu
  • next / previous (in terms of tab-ordering)
  • drag / drop

There are bound to be useful ones that I've missed, but I think it's worth
considering something like this for either DOM level 3 or DOM level 4,
because it should allow people to worry about higher-level interactions, and
worry less about low-level details when they don't need them.

For a simple example, suppose I am using the history API in my client-side
application, and I have a catch-all click event handler which is used to
handle navigation with the history API:

localFrame.addEventListener("click", function(event) {
  // ignore non-navigation roles
  if (event.role !== "navigate") return;

  // do the rest of the work
  if (resolveTemplateAndLoad(event.target.href))
    history.pushState(event.target.href, someData);
});

To take this a step further, it would be cool to be able to just listen for
specific interaction roles, rather than listening for a specific event. This
is because an interaction might take many different forms. I could scroll a
page with a mousewheel or arrow keys, or by using the scrollbar. I could
navigate to a new page by pressing enter or space on the currently focused
item. So that form of API might look more like this:

// Suppose a hash fragment following an event name were said to mean "listen
// only to events filtered by the specific role" --- It might step on DOM
// event names currently, but namespaced events are usually being handled
// differently, so it would probably be fine. Just an example, though!
localFrame.addEventListener("#navigate", function(event) {
  var href = event.target.href;
  if (resolveTemplateAndLoad(href))
    history.pushState(href, someData);
});

Listening for events of a specific role might be harder to polyfill, but it
would simplify a lot of client-side code, and I could see it being highly
useful for app developers.

I'm interested in hearing what people think about this, it seems like
something which could be fleshed out and implemented fairly easily. Maybe it
doesn't belong in DOM level 3, but it would be really cool if we could agree
on a way to do this nicely, and because of this, it would be great to hear
if anyone is interested in something like that.

Comment 2 caitp 2014-05-11 16:25:19 UTC

I've been looking over the IndieUI proposals, and I think it covers some of this, but not all of it, and not necessarily very well.

Adding new event types seems like a non-solution which complicates things further. Instead, annotating existing events with a role for their particular UI interaction, and providing a way to listen to events filtered based on the annotated interaction, seems much simpler, and easier to polyfill.

But I suppose discussions about that would be better suited for the IndieUI WG.

But it's good that there's at least an interest in working with high-level interactions rather than low-level inputs, so that's great.

Comment 3 Travis Leithead [MSFT] 2014-05-12 18:58:47 UTC

(In reply to caitp from comment #2)

I've been looking over the IndieUI proposals, and I think it covers some of
this, but not all of it, and not necessarily very well.

Adding new event types seems like a non-solution which complicates things
further. Instead, annotating existing events with a role for their
particular UI interaction, and providing a way to listen to events filtered
based on the annotated interaction, seems much simpler, and easier to
polyfill.

But I suppose discussions about that would be better suited for the IndieUI
WG.

But it's good that there's at least an interest in working with high-level
interactions rather than low-level inputs, so that's great.

Thanks! There may be something we can add in to some events to improve the situation.

Note: moving to UI Events path which is where future work and feature requests are being collected at the moment.

[Proposal] Add "Zoom" event

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26611

Masayuki Nakano 2014-08-20 07:14:47 UTC

Mozilla have a bug report about a way to prevent content zoom by web apps.
https://bugzilla.mozilla.org/show_bug.cgi?id=1052253

According to the bug report, Chrome fires a wheel event whose ctrlKey is true when user attempts to "pinch to zoom" on Mac. Then, if the wheel event's default is prevented, Chrome cancels the zoom.

On the other hand, Firefox doesn't fire any events at "pinch to zoom" on Mac. Therefore, web apps cannot prevent to zoom. Of course, Firefox can dispatch such wheel event. However, Firefox users can customize a way to zoom with wheel. E.g., they can use Option (Alt) key for it and/or reverse the direction. Therefore, web apps cannot distinguish which wheel event is a "before zoom" event strictly.

I'd like to suggest a simple event "Zoom". When users attempt to use zoom feature of browsers from keyboard shortcut, wheel or menu, it should be fired. And if its default is prevented, browser should cancel it.

I think that UIEvent is enough for the event. Its detail value should be |new zoom level * 100| or just 1 or -1 for indicating zooming in or out.

Comment 1 Masayuki Nakano 2014-08-20 07:19:20 UTC

If we do create new interface for zoom event, it should have:

double level; (110 means 110%)
boolean fullZoom; (full zoom or text only zoom)
unsigned long device; (0: unknown, 1: key, 2: mouse, 3: gesture)

Comment 2 Mounir Lamouri 2014-08-20 08:51:57 UTC

Both Firefox and Chrome expose the zoom level via devicePixelRatio change. Should we have a devicePixelRatio change event or do we want to expose an entirely different feature (zoom level + change events)?

Exposing the zoom level and preventing zoom changes is something that Chrome Apps was looking into so it sounds like we definitely have UC for that.

Comment 3 Olli Pettay 2014-08-20 09:19:11 UTC

devicePixelRatio is changed after the user intent has been processed by the
browser.
Zoom (or wheel+ctrl) happens before actual zooming.
So devicePixelRatio isn't really about this bug.

Comment 4 Evan Wallace 2014-08-20 16:29:57 UTC

The intent isn't just to be able to prevent the default zoom behavior, but also to be able to implement custom zoom behavior. For example, a zoom event in a map application over the map area wouldn't zoom the entire page but would zoom the map instead.

As an app developer, zoom events are easiest to use for custom zoom behavior when the detail value just provides an incremental delta instead of the absolute zoom level. For example, if a keyboard zoom in/out action is part of this event, then either a multiplicative delta of *2 or *0.5 or an additive delta of +1 or -1 (in log space, so the scale is something like *pow(2, additiveDelta)) would be the most useful.

Providing the absolute zoom level in the event is inconvenient because the application likely has its own representation of zoom that has nothing to do with the browser zoom. For example, the scale of the map in a map application usually changes by 100x during a session. Tying the scale of the map to the absolute zoom level doesn't make sense.

Comment 5 Tetsuharu OHZEKI 2014-08-20 17:57:14 UTC

I have some questions about this intent:

As Evan remarks, If this intent is not suitable to prevent the default zoom behavior and we should use viewport's user-zoom=fixed to prevent it, but if we introduce this intent to make a custom behavior, will UA fires this "zoom" event?

And I think "zoom" is an abstract behavior indicated by user. Is it really suitable to add this intent to DOM3 Event? I remember IndieUI Events which represents user's high abstract indication. so I feel we should add this to its spec, shouldn't it?
(I don't know IndieUI spec status well. if we cannot wait it, I vote passively that to add this intent to DOM3 Event.)

Comment 6 Masayuki Nakano 2014-08-21 01:35:29 UTC

(In reply to Evan Wallace from comment #4)

As an app developer, zoom events are easiest to use for custom zoom behavior
when the detail value just provides an incremental delta instead of the
absolute zoom level. For example, if a keyboard zoom in/out action is part
of this event, then either a multiplicative delta of *2 or *0.5 or an
additive delta of +1 or -1 (in log space, so the scale is something like
*pow(2, additiveDelta)) would be the most useful.

Sounds better to me.

(In reply to Tetsuharu OHZEKI from comment #5)

As Evan remarks, If this intent is not suitable to prevent the default zoom
behavior and we should use viewport's user-zoom=fixed to prevent it, but
if we introduce this intent to make a custom behavior, will UA fires this
"zoom" event?

"zoom" event should be fired immediately before the browser attempts to zoom its content. I believe that even if zoom won't occur actually (e.g., already reached to min or max zoom level or user-zoom: fixed, zoom event should be fired because the important feature of this event is that web contents should be able to know when the user tries to zoom in/out the content.

And I think "zoom" is an abstract behavior indicated by user. Is it really
suitable to add this intent to DOM3 Event? I remember IndieUI Events which
represents user's high abstract indication. so I feel we should add this to
its spec, shouldn't it?
(I don't know IndieUI spec status well. if we cannot wait it, I vote
passively that to add this intent to DOM3 Event.)

Oh, I've not known IndieUI Events. Indeed, it includes zoom related events. However, looks like the spec is too unstable...

Comment 7 Arthur Barstow 2015-03-21 15:11:52 UTC

Bulk move of all D3E bugs to the UI Events component.

Comment 8 Rick Byers 2015-07-07 14:23:35 UTC

I'm in favor of adding such an API, but I'd prefer if it was rich enough to also support touchscreen pinch zoom (would be weird if we fired it in all zoom scenarios other than that). So we'd probably want to include a co-ordinate with the event (so that pinch/drag still tracks your fingers). But then it's not clear what co-ordinates we'd use for keyboard zoom. We also need to be careful with the scale to ensure pinch-zoom sticks to your fingers.

Rather than a device integer as suggested in #c1, I'd want to leverage UIEvent.sourceDevice (rbyers.github.io/InputDevice/inputdevice.html).

Sounds like we should talk to Dean Jackson at Apple to make sure we get an API they'd be happy with: https://twitter.com/RickByers/status/618380969343451136

If we're going to do all this, then perhaps it should have zoombegin/zoomend events too (or some equivalent way to know when the user lifts their fingers off the trackpad / touchscreen - maybe a simple 'boolean isEnding' is sufficient).

Define key names for game controller of Android

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21137

Masayuki Nakano 2013-02-27 04:28:09 UTC

Android defines following key code values. For them, D3E should define the key names.

Android Suggestions

KEYCODE_BUTTON_A 'GameButtonA' as Game
KEYCODE_BUTTON_B 'GameButtonB'
KEYCODE_BUTTON_C 'GameButtonC'
KEYCODE_BUTTON_X 'GameButtonX'
KEYCODE_BUTTON_Y 'GameButtonY'
KEYCODE_BUTTON_Z 'GameButtonZ'
KEYCODE_BUTTON_L1 'GameButtonL1'
KEYCODE_BUTTON_R1 'GameButtonR1'
KEYCODE_BUTTON_L2 'GameButtonL2'
KEYCODE_BUTTON_R2 'GameButtonR2'
KEYCODE_BUTTON_THUMBL 'GameButtonThumbL'
KEYCODE_BUTTON_THUMBR 'GameButtonThumbR'
KEYCODE_BUTTON_START 'GameButtonStart'
KEYCODE_BUTTON_SELECT 'GameButtonSelect'
KEYCODE_BUTTON_MODE 'GameButtonMode'
KEYCODE_BUTTON_1 'GameButton1'
KEYCODE_BUTTON_2 'GameButton2'
KEYCODE_BUTTON_3 'GameButton3'
KEYCODE_BUTTON_4 'GameButton4'
KEYCODE_BUTTON_5 'GameButton5'
KEYCODE_BUTTON_6 'GameButton6'
KEYCODE_BUTTON_7 'GameButton7'
KEYCODE_BUTTON_8 'GameButton8'
KEYCODE_BUTTON_9 'GameButton9'
KEYCODE_BUTTON_10 'GameButton10'
KEYCODE_BUTTON_11 'GameButton11'
KEYCODE_BUTTON_12 'GameButton12'
KEYCODE_BUTTON_13 'GameButton13'
KEYCODE_BUTTON_14 'GameButton14'
KEYCODE_BUTTON_15 'GameButton15'
KEYCODE_BUTTON_16 'GameButton16'

Comment 1 Glenn Maynard 2013-02-27 04:52:20 UTC

I can't even tell what you're trying to do here. No web API should be trying to define every input symbol of every random API in the industry.

Comment 2 Masayuki Nakano 2013-02-27 06:05:30 UTC

(In reply to comment #1)

I can't even tell what you're trying to do here. No web API should be
trying to define every input symbol of every random API in the industry.

I believe that D3E spec should define key names which will be used in major platforms as far as possible because if it wouldn't define them clearly, it'd be possible each UA vendors to give different names for same key.

If this is wrong, the ".key" approach is failure since it allows different key names, which means ".key" is not web developer friendly.

Comment 3 Glenn Maynard 2013-03-05 00:35:21 UTC

(In reply to comment #2)

I believe that D3E spec should define key names which will be used in major
platforms as far as possible because if it wouldn't define them clearly,
it'd be possible each UA vendors to give different names for same key.

If this is wrong, the ".key" approach is failure since it allows different
key names, which means ".key" is not web developer friendly.

What does "GameButtonX" mean? On a PSX controller, the button labelled "X" is in the bottom-left, and is usually a primary control. On a 360 controller, it's the top-left button and is usually a secondary input. On whatever input device Android is exposing, it might mean something completely different. Saying that "GameButtonX" maps to "KEYCODE_BUTTON_X on Android" doesn't give a useful definition on anything that isn't Android.

Being told "the user pressed GameButtonY" doesn't tell the web developer anything. It doesn't even mean "pushed a button with a Y on it"--it might be a controller with PSX labels, which has symbols rather than letters.

(For that matter, why are gamepad controllers being mapped like keys? They should be exposed with a joystick API, not generate key events.)

Comment 4 Masayuki Nakano 2013-03-05 01:57:10 UTC

(In reply to comment #3)

(In reply to comment #2)

I believe that D3E spec should define key names which will be used in major
platforms as far as possible because if it wouldn't define them clearly,
it'd be possible each UA vendors to give different names for same key.

If this is wrong, the ".key" approach is failure since it allows different
key names, which means ".key" is not web developer friendly.

What does "GameButtonX" mean? On a PSX controller, the button labelled "X"
is in the bottom-left, and is usually a primary control. On a 360
controller, it's the top-left button and is usually a secondary input. On
whatever input device Android is exposing, it might mean something
completely different. Saying that "GameButtonX" maps to "KEYCODE_BUTTON_X
on Android" doesn't give a useful definition on anything that isn't Android.

Being told "the user pressed GameButtonY" doesn't tell the web developer
anything. It doesn't even mean "pushed a button with a Y on it"--it might
be a controller with PSX labels, which has symbols rather than letters.

Absolutely. However, I believe that it's impossible to tell the button position on any platform. E.g., see the controllers for PS3 or XBOX 360 in game stores. The button position can be changed by the controller vender. Actually, controller pad and joy stick like arcade video game machine have different layout. However, most game has button configuration and they handle each buttons.

So, web application as game platform needs to implement button configuration on each application since there are a lot of different environment. But then, the platform information and the key name should help the developers to decide default button configuration. So, I think that .key for games is useful if the developer checks the platform name. Therefore, I think it does make sense to tell "button Y pressed" with key event to web applications for their developers.

(For that matter, why are gamepad controllers being mapped like keys? They
should be exposed with a joystick API, not generate key events.)

Is there such draft? And you think that any web platforms must not generate key events for all buttons on game pad or joy stick?

Comment 5 Olli Pettay 2013-03-05 08:55:17 UTC

(In reply to comment #4)

Is there such draft? And you think that any web platforms must not generate
key events for all buttons on game pad or joy stick?

https://bugzilla.mozilla.org/show_bug.cgi?id=604039
https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html

Comment 6 Masayuki Nakano 2013-03-05 11:48:57 UTC

Thank you for the information.

Do you think that UA shouldn't dispatch DOM key events for joy stick's button? If yes, why the keyboard location has "joystick" value?

Comment 7 Olli Pettay 2013-03-05 12:00:03 UTC

(In reply to comment #6)

Do you think that UA shouldn't dispatch DOM key events for joy stick's
button?

Not sure. At least it isn't super important if Gamepad API is supported.

If yes, why the keyboard location has "joystick" value?

Well, D3E is older than Gamepad API.

Comment 8 Glenn Maynard 2013-03-07 01:47:20 UTC

(In reply to comment #4)

Being told "the user pressed GameButtonY" doesn't tell the web developer
anything. It doesn't even mean "pushed a button with a Y on it"--it might
be a controller with PSX labels, which has symbols rather than letters.

Absolutely. However, I believe that it's impossible to tell the button
position on any platform. E.g., see the controllers for PS3 or XBOX 360 in
game stores. The button position can be changed by the controller vender.

Not at all. It's not hard to tell that you're on a 360 controller, and to map things appropriately. Any competent joystick API will handle this, giving implementation direction for common controllers, so games using the API can have sensible default mappings for various production controllers. But, this isn't a gamepad API trying to solve these problems.

So, web application as game platform needs to implement button configuration
on each application since there are a lot of different environment. But
then, the platform information and the key name should help the developers
to decide default button configuration. So, I think that .key for games is
useful if the developer checks the platform name. Therefore, I think it does
make sense to tell "button Y pressed" with key event to web applications for
their developers.

Woah, wait. Hold up. You're designing a web API with the expectation of people using UA sniffing to figure out what the symbols mean?

Comment 9 Masayuki Nakano 2013-03-07 05:19:21 UTC

(In reply to comment #8)

(In reply to comment #4)

Being told "the user pressed GameButtonY" doesn't tell the web developer
anything. It doesn't even mean "pushed a button with a Y on it"--it might
be a controller with PSX labels, which has symbols rather than letters.

Absolutely. However, I believe that it's impossible to tell the button
position on any platform. E.g., see the controllers for PS3 or XBOX 360 in
game stores. The button position can be changed by the controller vender.

Not at all. It's not hard to tell that you're on a 360 controller, and to
map things appropriately. Any competent joystick API will handle this,
giving implementation direction for common controllers, so games using the
API can have sensible default mappings for various production controllers.
But, this isn't a gamepad API trying to solve these problems.

I meant that even if the button is labeled "L1", the button isn't like a trigger key if the controller is a joystick. So, telling which button is being pressed to web developer with any API set never tells actual meaning.

So, web application as game platform needs to implement button configuration
on each application since there are a lot of different environment. But
then, the platform information and the key name should help the developers
to decide default button configuration. So, I think that .key for games is
useful if the developer checks the platform name. Therefore, I think it does
make sense to tell "button Y pressed" with key event to web applications for
their developers.

Woah, wait. Hold up. You're designing a web API with the expectation of
people using UA sniffing to figure out what the symbols mean?

I think that the important thing for web developers is, they can distinguish the pressed button from other buttons. I think the description of the last part (* of GameButton*) does NOT tell useful information to web developers.

Like Android, if there is no reference hardware design on the platform, probably web game developers need to check the UA or hardware vender for providing better default button settings for their users.

On the other hand, if there is a reference hardware design like XBOX or PS, web game developers can provide better default button settings with the platform information.

But if KeyboardEvent.key doesn't provide the button names, they cannot distinguish the buttons and if it's not defined in D3E spec, UA implementers might define different button names for same buttons on Android. Therefore, I filed this bug for the compatibility between web browsers on Android.

Testing DOM L3 Events

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25967

Travis Leithead [MSFT] 2014-06-04 00:35:08 UTC

Here's what I've found in web-platform-tests:

Comment 1 Arthur Barstow 2015-03-21 15:12:03 UTC

Bulk move of all D3E bugs to the UI Events component.

[key] Separator

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27129

Habib Virji 2014-10-22 15:41:54 UTC

"'Separator' "

Which keys does this key maps to. Is the separator here referred to only period?

Comment 1 Masayuki Nakano 2014-10-28 01:32:20 UTC

Separator should have been used for a key to input a separator (like comma of "10,000"). But such key value should be actual inputting text. So, I believe that this was just forgotten when similar key values were removed.

Comment 2 Arthur Barstow 2015-03-21 15:12:02 UTC

Bulk move of all D3E bugs to the UI Events component.

Expose ticks in wheel events

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23259

Gary Kacmarcik 2013-09-16 21:55:51 UTC

We should consider adding |ticks| to the wheel event.

There are many UX use cases where ticks are more appropriate than pixels, especially considering that pixel values vary from system-to-system (and can vary based on user preferences).

An example of when ticks are more appropriate is with a "digit-selector", a menu or a drop-down list. In each of these cases, a single tick should select the next element regardless of how many "pixels" are reported.

Issues:
What ticks value should be used for input devices that fake scrollwheel events (like a touchpad)? Options are to simply use 0 ticks for these devices, come up with a method for generating fake ticks.

Do we need x, y and z ticks?

Comment 1 Gary Kacmarcik 2013-10-23 13:53:26 UTC

Moving to UI Events

Needs clearer definition of virtual keyboard's KeyboardEvent.code value if it doesn't emulate physical key event completely

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25968

Masayuki Nakano 2014-06-04 00:43:55 UTC

[09:33] If a VKB doesn't emulate native physical key event completely, there are 2 patterns:
[09:34] One is there is an API to compute scancode from virtual keycode. This is Windows' case. At this time, browsers can use the API and compute .code value from the result.
[09:35] I filed a bug for us to start investigating tests: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25967
[09:36] The other is, the is not such API. E.g., Android. At this time, browsers can guess non-printable keys and some printable keys which can guess the key position from virtual keycode name. E.g., it has NUMPAD or something.
[09:36] I don't expect all VKBs to provide useful 'code' values for every key.
[09:36] They should if they want to emulate a physical keyboard, but not all VKBs care about that.
[09:37] In the latter case, browsers should NOT set .code values for printable keys which must be in standard position because VK -> SC depends on keyboard layout.
[09:39] https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#code-virtual-keyboards
[09:39] VKBs that emulate a physical keyboard should be emulating a particular layout as well - so they should know what positions to use.
[09:39] This looks like that D3E spec recommends that browsers should guess the key position even in such case.
[09:40] So I would expect a virtual french keyboard (with standard layout) to use 'KeyA' for the key labeled 'q'.
[09:41] If they completely change the layout for the VKB, then the 'code' doesn't have much use.
[09:41] I'd like you to document about the latter case in the spec even if the VKB looks like emulating physical keyboard but not generating scancode properly.

Comment 1 Masayuki Nakano 2014-06-04 00:54:11 UTC

My most important suggestion is, browsers SHOULD NOT try to guess code values of printable keys in standard position when a VKB doesn't emulate native physical keyboard event (i.e., no scancode) and the platform doesn't have API to compute scancode from virtual keycode.

If browsers did guess in such case, .code value would be untrusted attribute in such situation but web developers couldn't know whether they were in such case.

Comment 2 Masayuki Nakano 2014-06-04 01:24:56 UTC

And Olli thinks that it's odd to guess non-printable .code value when browsers are not sure the printable keys' code values.
https://bugzilla.mozilla.org/show_bug.cgi?id=1017383#c2

I think that it's okay browsers to set proper code value when a native virtual keycode includes position information e.g., SHIFT_LEFT, SHIFT_RIGHT, or is only generated with a scan value like SPACE.

However, indeed, if browsers shouldn't guess code value always, it makes the spec and behavior simpler.

Comment 3 Arthur Barstow 2015-03-21 15:11:57 UTC

Bulk move of all D3E bugs to the UI Events component.

Specify MouseEvent.which

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27558

Philip Jägenstedt 2014-12-10 22:40:04 UTC

Every browser I tested supports this.

In Gecko it's simply button + 1.

In Blink/WebKit it's button + 1 except when button is 65535, in which case it's explicitly wrapped around to 0. This is odd and probably doesn't matter.

I suggest spec'ing the Gecko behavior.

Comment 1 Arthur Barstow 2015-03-21 15:12:08 UTC

Bulk move of all D3E bugs to the UI Events component.

Comment 2 Philip Jägenstedt 2015-07-10 12:06:29 UTC

Ping?

Usage is very high:
https://www.chromestatus.com/metrics/feature/timeline/popularity/595

In Gecko and WebKit, which is on the UIEvent prototype only.

That was previously the case in Blink as well, but I added it to MouseEvent and KeyboardEvent to shadow the one on UIEvent in order to measure the usage for non-mouse/keyboard events where it always returns 0:
https://www.chromestatus.com/metrics/feature/timeline/popularity/598

In IE, it looks like which is on the KeyboardEvent and MouseEvent prototype only, not on UIEvent.

Moving it up to UIEvent or adding it to MouseEvent would be OK, and the difference is in who gets to take the risk when aligning with the spec.

Comment 3 Rick Byers 2015-07-10 13:29:12 UTC

This sounds like the always-0 UIEvent.pageX/pageY difference Ted (IE team) reported caused an actual compatibility issue for them: https://groups.google.com/a/chromium.org/d/msg/input-dev/4p1XZy_17aw/qi-LQuOtvpcJ

So I think it's worth trying to align the Gecko, Blink, Webkit and Edge behavior here.

I don't really trust the use-counter data here as a reliable indicator of risk - I suspect most uses will do just as fine with undefined as they did with 0. But I don't have any hard data. If blink's pageX/pageY change goes smoothly, then I'd be willing to try moving 'which' as well.

Alternately just standardizing it on UIEvent is the simpler option, so fine with me also. It's a little uglier, but 'which' is going to be ugly no matter what way we look at it.

Ted, any thoughts?

If we can get some agreement between vendors here, then I suggest we make a concrete pull-request to the UIEvents spec.

Comment 4 Philip Jägenstedt 2015-07-10 13:43:45 UTC

Boris, Olli, looks like you've both poked at these three interfaces in Gecko from time to time. What say you?

Comment 5 Olli Pettay 2015-07-10 13:50:53 UTC

Keeping it in UIEvent kind of makes sense since more than one interface extending UIEvent want .which.
Also, .which has been in UIEvent forever, so I don't see strong reasons to move it.

But I don't strongly object to move it to Mouse/Keyboard events either.
Just don't quite see the point of making the change for the sake of change -
the API isn't significantly better or worse wherever .which lives.

Comment 6 Philip Jägenstedt 2015-07-10 13:55:35 UTC

I agree that would be a quicker way to getting everything aligned and forgetting about this. Anyone from Microsoft have a problem with moving it up to UIEvent in IE?

Comment 7 Rick Byers 2015-07-10 14:03:26 UTC

Yeah that was my initial reaction too (i.e. unlike pageX/pageY - which really does have meaning on more than one type of UIEvent). However the meaning is completely different depending on the interface. It's pretty odd to have API docs like:

UIEvent.which:

  • on KeyboardEvent this is the key code. On MouseEvent it's the button pressed.

Makes a lot more sense to just have separate docs on MouseEvent and KeyboardEvent (which MDN does have by the way - with the docs for UIEvent.which being incomplete).

Also I just checked to see if I could find an example of a site accessing 'which' for a non-keyboard non-mouse event. I immediately found this code in GMail operating on a FocusEvent ('a'):

    for (c in a)
        b[c] = a[c];

So again (like the discussion here: https://groups.google.com/a/chromium.org/d/msg/blink-dev/pjohnl9znQQ/eHvq4U6E2skJ) access is due to an event library attempting to make a copy of the event.

But I agree with Olli that it may not be worth the effort. Anyone from IE want to weigh in since they'd be the one that would have to change?

Comment 8 Travis Leithead [MSFT] 2015-07-10 17:56:06 UTC

In IE/Edge, which is implemented on MouseEvent and KeyboardEvent. Moving it to the UIEvent interface exposes it to many other interfaces that don't really need it. Since this is a compatibility API, I'd prefer not to spec it on UIEvent directly.

Comment 9 Philip Jägenstedt 2015-07-10 18:00:23 UTC

As I said, I'm OK either way, but I'll assume then that the spec will have MouseEvent.which soonish and that we should try to remove it from the UIEvent prototype.

Comment 10 Rick Byers 2015-07-10 18:15:27 UTC

That's fine with me. Spec it on MouseEvent and KeyboardEvent and we'll attempt to move it in blink. Of course if we hit compat issues then we'll have to have to talk :-). But if Edge hasn't already had compat issues here, then I'm sure it'll be fine.

specify how compositionend works if the caret has been moved to a different element

If one moves the caret/selection to a different element when compoisitionstart is triggered, browsers different on compositionend:

  1. Chrome/Safari trigger the compositionend event on the element where composition takes place.
  2. Firefox triggers the compositionend event on the element where the caret was at the time when the compositionstart event was triggered.

Additionally, browsers behave differently if the caret is moved to a different element when compositionend is triggered:

  1. Chrome/Safari paste the composed characters in the place where the caret is moved to.
  2. Firefox moves the caret to a different element and inserts no characters there by default. If the JS inserts the characters by means of execCommand/insertHTML, the endComposition event is triggered a second time.

The Chrome/Safari behavior is desired for the use case where one wants to have IME character insertion into the document stream be atomic -- either by doing composition somewhere else [1] or by using a Shadow DOM during composition [2].

[1] http://jsbin.com/wimuqowimu/15/edit?html,js,console,output (works in Chrome/FF)
[2] http://jsbin.com/pacisugiwu/1/edit?html,js,output (only works in Chrome)

Edge behavior is close to FF behavior and Safari close to Chrome.

See also debate about this here: https://lists.w3.org/Archives/Public/www-dom/2015JulSep/0044.html

D3E and corelation with DOM4(W3C)/DOM(WHATWAG) and DOM3 Core

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25485

Arkadiusz Michalski (Spirit) 2014-04-27 18:20:46 UTC

(In reply to Gary Kacmarcik)

Re: change ref to DOM3 Core. There has been no discussion of that, but if you
feel it should be changed, please open a bug for that so that we can discuss it.

and Anne comment (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25359#c5)

any plans for changing ref to a more current spec? I see that D3E was started a long time ago (Tom Pixley, Netscape Communications Corporation (until Jul 2002)), and now still is not a recommendation.

Maybe will be better it this document would base on the current DOM spec, which at the moment has good quality (and exist in two version: W3C and WHATWG). Many other specifications for a long time refers to the latest DOM (including HTML5).

This change could simplify the base D3E document, we don't need again defined basic interface, like Event, CustomEvent, EventTarget, EventListener (and probably DocumentEvent too). And some definition would be more consistent (like 'dispatch' and 'fire', which in new DOM are not synonymous). Current implementations (like browsers) when introducing new things using only the latest version of the DOM. For this implementations some concepts from D3E are still something news, but their definitions include the old DOM refs.

If not changing this version of the document is worth considering such a change on the next version D3E. It's just my little thoughts, but if someone wants to write something specific (with justification) please feel free.

Comment 1 Anne 2014-04-28 08:32:14 UTC

Yes, I feel this is long overdue now. We tried to get DOM Level 3 Events out quickly, that never happened. At this point the duplication is simply causing confusion.

Comment 2 Arkadiusz Michalski (Spirit) 2014-05-14 07:04:02 UTC

If we remove the stuff covered in DOM4, then we remove Sections 3 and 4 (and a lot of glossary items)

In my opinion Section 3 is very helpful. DOM4 is economical in descriptions and has only two algorithms, but Section 3 explains everything in more detail (and other concepts, like synchronous/asynchronous, Activation triggers and behavior, etc...), has nice dispatched diagrams, just a good description for beginners (I am writing this from my own perspective and experience). Trying to understand all the basic things based only on the DOM4 (or HTML5) is difficult. Will be better just fit the text to the terminology DOM4, but not remove all.

Section 4 has nice diagram for interface inheritance which is also very useful, but descriptions for basic interfaces are unnecessary (you describe everything more details, but this info in most cases can be deduced directly from the DOM algorithms).

It's my small advice, both documents in some way complement each other (if we take into account the event processing).

Comment 3 Anne 2014-05-15 12:53:40 UTC

If you feel there's something missing in http://dom.spec.whatwg.org/ you should file a bug. This part of DOM Level 3 Events is obsoleted by that and will disappear in due course.

Comment 4 Arkadiusz Michalski (Spirit) 2014-05-19 21:18:17 UTC

Before make "big cleanup" please make last actual snapshot of current version for all, now last version (having its own link) derived from:

W3C Working Draft 06 September 2012
http://www.w3.org/TR/2012/WD-DOM-Level-3-Events-20120906/

This will make it easier to verify which possibly important things has been removed.

Comment 5 Travis Leithead [MSFT] 2014-05-28 00:07:44 UTC

We are putting together a proposed change for review. Should resolve the duplication between DOM4 and DOML3 Events.

Comment 6 Arthur Barstow 2015-03-21 15:12:01 UTC

Bulk move of all D3E bugs to the UI Events component.

Please mark some definitions as not exported

I added UI Events to Shepherd's linking database yesterday, and now we're running into problems due to it using <dfn> for a bunch of terms that it's actually just referencing from other specs.

The best solution, of course, is switching to a preprocessor that does cross-spec linking, but in the meantime there's an easy fix - just mark them all as not exported!

In particular, please add a data-no-export boolean attribute to:

  • The two *Error definitions in 3.6
  • The list of IDL definitions in 4.0. (You can put it on the list element, as it's a container for all of them.)

Consider adding sourceDevice property to UIEvent

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28938

Rick Byers 2015-07-10 19:21:01 UTC

Concrete proposal: http://rbyers.github.io/InputDevice/inputdevice.html

There's been a bit of support on www-dom for this (including from Gary): https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0120.html, but not much discussion.

We're pretty close to doing an intent-to-ship for blink on this, so it would be great if we could decide whether there is interest in adding this to UI Events (or possibly some other spec).

If there's interest, I'm happy to create a pull request.

Comment 1 Jacob Rossi [MSFT] 2015-07-13 18:53:57 UTC

We've discussed this scenario a few times in the Touch Events and Pointer Events groups. It seems useful to a certain set of folks. I don't have any initial concerns with your spec proposal. Most of my questions stem from the roadmap for this feature beyond just firesTouchEvents. Do you have any consumers of the polyfill that are helping validate this satisfies their needs?

Given we're creating a new interface here for this rather than a single property, I'd love to know if you have a scope in mind for what other types of information might eventually get added to SourceDevice (is it input characteristic properties, such as discussed in [1], or just info about how the events/model will be processed like firesTouchEvents; should we also have a firesPointerEvents property?).

Given it seems set up intentionally for more members than just the one in the spec today and given UI Events is fairly far along as a spec, I think this makes more sense as a standalone spec in the new Incubator Community Group.

[1]https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0121.html

Comment 2 Rick Byers 2015-07-24 15:56:52 UTC

(In reply to Jacob Rossi [MSFT] from comment #1)

We've discussed this scenario a few times in the Touch Events and Pointer
Events groups. It seems useful to a certain set of folks. I don't have any
initial concerns with your spec proposal. Most of my questions stem from the
roadmap for this feature beyond just firesTouchEvents. Do you have any
consumers of the polyfill that are helping validate this satisfies their
needs?

Not directly, no. I've been working with the Google+ team, but they long ago wrote a library that behaves like my polyfill does and (after struggling with various hacks to this problem for years) they're now happy with it and so have little reason to switch to a different polyfill. They've reviewed the spec though and have expressed their support for it.

Given we're creating a new interface here for this rather than a single
property, I'd love to know if you have a scope in mind for what other types
of information might eventually get added to SourceDevice (is it input
characteristic properties, such as discussed in [1], or just info about how
the events/model will be processed like firesTouchEvents; should we also
have a firesPointerEvents property?).

The former. Eg. I could certainly imagine 'supportsTilt', 'maxContactPoints' etc. properties, as well as possibly an API to enumerate all the input devices in the system (i.e. it's about exposing the state of the system, not some event-context-dependent thing). To me this is the future for PointerEvent.pointerType that we've discussed a few times (eg. if some 4th pointer type comes along - will we really be able to add another pointer type string while still being compatible with existing code?). This brainstorming doc [2] is the outcome of the www-dom thread about what a possible future for this API might look like.

[2] https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit#

Given it seems set up intentionally for more members than just the one in
the spec today and given UI Events is fairly far along as a spec, I think
this makes more sense as a standalone spec in the new Incubator Community
Group.

SGTM. Discourse thread started here: http://discourse.wicg.io/t/inputdevice-api-for-identifying-mouse-events-derived-from-touch/972/1. I'm happy to call this bug 'WONTFIX' if others agree. I know Gary wanted to use this API for some keyboard scenarios, so perhaps he should weigh in on what he sees the right next steps to standardization being.

[1]https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0121.html

[code] KeyboardEvent code spec should have featurephone section

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27996

Masayuki Nakano 2015-02-11 01:53:20 UTC

D3E KeyboardEvent should cover the keys on featurephone because featurephone is still major device.

Therefore, D3E-code spec should have a section to explain which code values should be used if they can be distinguished, and also if they cannot be distinguished, which scancode for existing code values should be generated by the driver.

Our agreements are now, Numpad* for them but not yet discussed enough about the latter case.

Comment 1 Arthur Barstow 2015-03-21 15:11:50 UTC

Bulk move of all D3E bugs to the UI Events component.

KeyboardEvent.locale is too general

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21830

Travis Leithead [MSFT] 2013-04-25 19:28:30 UTC

The KeyboardEvent.locale property is underspecified. BCP-47 is too general, we need to get much more crip on what sub-set of these strings are reasonable and which are not.

Eg., there is a dvorak BCP-47 string. Should this be reported?

Goal should be to simplify the set.

Comment 1 Masayuki Nakano 2013-04-30 00:00:04 UTC

It's good timing. I tried implementing KeyboardEvent.locale and CompositionEvent.locale on Gecko.

Then, I worked on Windows and Mac. I think there is no API on Linux (except directly accessing IM framework such as iBus, SCIM). I'm still investigating about Android, though.

On Windows, we can make conversion table with:
http://msdn.microsoft.com/en-us/goglobal/bb896001.aspx
-- I guess that IE 9 also used this table.

On Mac, we can get the language property of current TIS with kTISPropertyInputSourceLanguages.
https://developer.apple.com/library/mac/#documentation/TextFonts/Reference/TextInputSourcesReference/Reference/reference.html

Then, on Mac, we cannot return locale. E.g., cannot return en-US, can just return en.

And IE 10 returns "zh-CN" for simplified Chinese. However, on Mac, we can returns "zh-Hans". So, I have no idea to implement with good compatibility between platforms.

So, I'm now thinking that .locale is not useful for web developers under current spec.

Comment 2 Masayuki Nakano 2013-04-30 05:07:54 UTC

The draft patches for Gecko are here:
https://bugzilla.mozilla.org/show_bug.cgi?id=680832

Comment 3 Gary Kacmarcik 2013-05-17 18:09:00 UTC

We may want to move KeyboardEvent.locale into UI Events so that we can take the time to define it properly.

Nothing in D3E relies on KeyboardEvent.locale, but UI Events has a few methods that want to make use of it.

Comment 4 Gary Kacmarcik 2013-11-14 09:00:41 UTC

The locale attribute has been moved into UI Events.

Converge with CSSOM-View

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25928

Anne 2014-05-30 18:27:08 UTC

Seems like it might be time to fix this weirdness: http://www.w3.org/TR/cssom-view/#extensions-to-the-mouseevent-interface

Change stuff from integers to floats, add the missing members, and define the members better.

Comment 1 Travis Leithead [MSFT] 2014-05-30 18:42:11 UTC

Awesome. Thanks for the head's up.

Comment 2 Arthur Barstow 2015-03-21 15:11:51 UTC

Bulk move of all D3E bugs to the UI Events component.

Define that click doesn't fire on disabled elements

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26227

Ms2ger 2014-06-27 21:21:54 UTC

The HTML spec has:

A form control that is disabled must prevent any click events that are
queued on the user interaction task source from being dispatched on the
element.

It would be better if this was defined, or at least referenced, in the spec that actually fires these events.

Comment 1 Ms2ger 2014-07-29 10:10:44 UTC

Also for options at http://www.whatwg.org/html/#concept-option-disabled.

Comment 2 Arthur Barstow 2015-03-21 15:11:58 UTC

Bulk move of all D3E bugs to the UI Events component.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.