Action-1750: review of UI Events

Here's my review of UI Events for Action 1750.

General:
We should consider doing an AAM for events, including this spec.

I like the way this spec handles deprecation. Maybe ARIA could do something similar?
1.2.1
all the interfaces and events with their associated methods, attributes, and semantics defined in this specification with the exception of those marked as deprecated<https://w3c.github.io/uievents/#deprecates> (a conforming user agent MAY implement the deprecated interfaces, events, or APIs for backwards compatibility, but is not required to do so in order to be conforming)

1.2.2
A content authoring tool MUST NOT claim conformance to UI Events for content it produces which uses features of this specification marked as deprecated<https://w3c.github.io/uievents/#deprecates> in this specification.

1.2.3
A content author SHOULD NOT use features of this specification marked as deprecated<https://w3c.github.io/uievents/#deprecates>, but SHOULD rely instead upon replacement mechanisms defined in this specification and elsewhere.


3.2 typo
Default actions<https://w3c.github.io/uievents/#default-action> are usually be performed after the event dispatch has been completed, but in exceptional cases they may also be performed immediately before the event is dispatched.

3.4 good, I think. Calling click is used as a work-around in some authoring guidance. Edge calls click whenever there is an inbound UIA event (invoke, toggle, select, etc.)

"Most untrusted events will not trigger default actions<https://w3c.github.io/uievents/#default-action>, with the exception of the click<https://w3c.github.io/uievents/#click> event. This event always triggers the default action<https://w3c.github.io/uievents/#default-action>, even if the isTrusted<https://dom.spec.whatwg.org/#dom-event-istrusted> attribute is false (this behavior is retained for backward-compatibility). All other untrusted events behave as if the preventDefault()<https://dom.spec.whatwg.org/#dom-event-preventdefault> method had been called on that event."

There is some duplication here with HTML 5 spec, and maybe this should just refer to that instead?

3.5. Activation triggers and behavior
I discussed this with Travis, and we think that this should probably just refer to the equivalent section in HTML5, instead of duplicating part of it.

Certain event targets<https://w3c.github.io/uievents/#event-target> (such as a link or button element) may have associated activation behavior<https://w3c.github.io/uievents/#activation-behavior> (such a following a link) that implementations perform in response to an activation trigger<https://w3c.github.io/uievents/#activation-trigger> (such as clicking a link).
Both HTML and SVG have an <a> element which indicates a link. Relevant activation triggers<https://w3c.github.io/uievents/#activation-trigger> for an <a> element are a click<https://w3c.github.io/uievents/#click> event on the text or image content of the <a> element, or a keydown<https://w3c.github.io/uievents/#keydown> event with a key<https://w3c.github.io/uievents/#dom-keyboardevent-key> attribute value of "Enter<http://www.w3.org/TR/uievents-key/#key-Enter>" key when the <a> element has focus. The activation behavior for an <a> element is normally to change the content of the window to the content of the new document, in the case of external links, or to reposition the current document relative to the new anchor, in the case of internal links.
An activation trigger<https://w3c.github.io/uievents/#activation-trigger> is a user action or an event which indicates to the implementation that an activation behavior should be initiated. User-initiated activation triggers<https://w3c.github.io/uievents/#activation-trigger> include clicking a mouse button on an activatable element, pressing the Enter key when an activatable element has focus, or pressing a key that is somehow linked to an activatable element (a hotkey or access key) even when that element does not have focus. Event-based activation triggers<https://w3c.github.io/uievents/#activation-trigger> may include timer-based events that activate an element at a certain clock time or after a certain time period has elapsed, progress events after a certain action has been completed, or many other condition-based or state-based events.


4.1 and 9
Keypress is deprecated. This is because there wasn't implementation. Even though this feels most parallel to click, keydown is more widely supported. I think this is ok, given the implementation issues.

5.1.2 Event types
Some of these are closely related to ARIA and AAPI events. Do we need a mapping spec?
Error
Select
(load, unload, and resize are not as close)

5.2 focus events
Model is pretty rich. Does it map to AAPIs?

Event Type

Notes


User shifts focus

1

focusin<https://w3c.github.io/uievents/#focusin>

Sent before first target element receives focus

2

focus<https://w3c.github.io/uievents/#focus>

Sent after first target element receives focus


User shifts focus

3

focusout<https://w3c.github.io/uievents/#focusout>

Sent before first target element loses focus

4

focusin<https://w3c.github.io/uievents/#focusin>

Sent before second target element receives focus

5

blur<https://w3c.github.io/uievents/#blur>

Sent after first target element loses focus

6

focus<https://w3c.github.io/uievents/#focus>

Sent after second target element receives focus


This note concerns me.  Will there be conflicts?
This specification does not define the behavior of focus events when interacting with methods such as focus() or blur(). See the relevant specifications where those methods are defined for such behavior.

5.2.4 focusin and focusout bubble, focus and blur don't. Interesting... What's the use case here?

We need to make sure that the device-independent click event stays that way. Activation from 3.5 above is the same as click in the real world.  Suggest adding a sentence or paragraph about how hitting enter on an activatable element fires click on that element. This would tie in nicely with the (quite good) accessibility note in this section.

5.3.4.1 Click
The click<https://w3c.github.io/uievents/#click> event type MUST be dispatched on the topmost event target<https://w3c.github.io/uievents/#topmost-event-target> indicated by the pointer, when the user presses down and releases the primary pointer button, or otherwise activates the pointer in a manner that simulates such an action. The actuation method of the mouse button depends upon the pointer device and the environment configuration, e.g., it MAY depend on the screen location or the delay between the press and release of the pointing device button.

5.5 Input Events
"Input events are sent as notifications whenever the DOM is being updated"
Beforeinput and input.
These used to only apply to form elements. Text should make it more clear that these apply to any element that is in an editable state.

5.6 Keyboard events
Has key, code and location, and takes modifiers.
Nothing else unexpected here, and some cleanup of legacy behavior.

5.7 composition events
These are for IMEs. I discussed this with Travis, and speech is another use case they've been considering. Suggest adding some text to that effect.

9.3 keypress is deprecated (see notes above in 4.1)

9.4 mutation events are deprecated, refers to DOM4 Mutation Observer as replacement. Custom elements is also a way to do this, or use @is on existing element. This lets you watch a particular element.  Suggest adding something to the spec about this, or creating some WCAG techniques.