W3C

IndieUI: Events 1.0

Events for User Interface Independence

W3C Working Draft

This version:
http://www.w3.org/TR/2013/WD-indie-ui-events-20130730/
Latest published version:
http://www.w3.org/TR/indie-ui-events/
Latest editor's draft:
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html
Previous version:
http://www.w3.org/TR/2013/WD-indie-ui-events-20130122/
Editors:
James Craig, Apple Inc.
Michael Cooper, W3C

Copyright © 2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

IndieUI: Events 1.0 is an abstraction between physical, device-specific user interaction events and inferred user intent such as scrolling or changing values. This provides an intermediate layer between device- and modality-specific user interaction events, and the basic user interface functionality used by web applications. IndieUI: Events focuses on granular user interface interactions such as scrolling the view, canceling an action, changing the value of a user input widget, selecting a range, placing focus on an object, etc. Implementing platforms will combine modality-specific user input, user idiosyncratic heuristics to determine the specific corresponding Indie UI event, and send that to the web application in addition to the modality-specific input such as mouse or keyboard events, should applications wish to process it.

See the introduction for background and usage examples.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a Working Draft by the IndieUI Working Group (IndieUI WG) of the Web Accessibility Initiative. It contains incremental updates from the previous draft, which are summarized in Appendix B: Normative changes since the last public working draft. The IndieUI: Events tracker lists open issues and actions, and links to closed issues and actions, which are the basis for most of the previous and upcoming updates.. The task force continues to refine use cases and requirements and expects to publish a formal draft of requirements soon; feedback on these is encouraged as well as on the specification. Also see the IndieUI Overview. A history of changes to IndieUI: Events 1.0 is available.

Feedback on this draft specification is essential to success of the technology. The IndieUI WG asks in particular:

To comment on this document, send email to public-indie-ui-comments@w3.org (comment archive). Comments are requested by 13 September 2013. In-progress updates to the document may be viewed in the publicly visible editors' draft.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction

This section is non-normative.

1.1 Background

This section is non-normative.

Scripting usable interfaces can be difficult, especially when one considers that user interface design patterns differ across software platforms, hardware, and locales, and that those interactions can be further customized based on personal preference. Individuals are accustomed to the way the interface works on their own system, and their preferred interface frequently differs from that of the web application author's preferred interface.

For example, web application authors, wishing to intercept a user's intent to 'undo' the last action, need to "listen" for all of the following events:

It would be simpler to listen for a single, normalized request to 'undo' the previous action.

In addition to the general user interface challenges, custom interfaces often don't take into account users who access web content via assistive technologies that use alternate forms of input such as screen readers, switch interfaces, or speech-based command and control interfaces.

For example, a web page author may script a custom interface to look like a slider (e.g. one styled to look like an HTML 'range' input) and behave like a slider when using standard mouse input, but there is no standard way for the value of the slider to be controlled programmatically, so the control may not be usable without a mouse or other pointer-based input.

1.2 Goals

This section is non-normative.

The primary goals of this specification are declared as the following:

  1. Make it easier for web developers to author consistently usable interfaces that are input-agnostic and independent of a user's particular platform, hardware, locale, and preferences.
  2. Enable every type of control in these interfaces to be programmatically determinable and controllable by both mainstream and alternate forms of user input, including assistive technologies.
  3. Provide a clear path for web developers to smoothly transition from currently existing physical events to IndieUI events, during the period when implementations of IndieUI are incomplete.

1.3 Document Scope

This section is non-normative.

Decisions regarding which specific physical user interactions (keyboard combinations, gestures, speech, etc.) trigger IndieUI events are explicitly listed as out-of-scope in the Working Group charter. User interface is—and should be—defined and controlled by each operating system, rather than defined as part of any technical specification.

However, throughout this document are listed informative examples of certain keyboard and mouse events that may trigger each IndieUI event. There is no requirement for a user agent to implement these examples, and they are listed here purely to aid in clarifying the reader's conceptual understanding of each event, as well as illustrating certain UI differences between platforms. These informative examples will be limited to keyboard and mouse events, because those physical modalities have been common in software interaction for decades, and their use is familiar to most readers.

For example, it may be common for the ESC key to trigger a 'dismissrequest' event to close a dialog, but the specification does not require the user agent to use any particular physical event. It is an implementation detail, and left for the developers of each platform or assistive technology to determine whether ESC or some other interaction is the most appropriate way to trigger the 'dismissrequest' event. As long as there is a way to initiate each event, the user agent will be considered a conforming implementation.

1.4 Usage Examples

1.4.1 Dismissing a Modal Dialog

This section is non-normative.

The following example uses a 'dismissrequest' event to close or cancel out of a modal application dialog.

Example 1

<!-- Declare which IndieUI event(s) this element receives. -->
<dialog uiactions="dismiss" id="myDialog">
  ...
</dialog>

<script type="text/javascript">


  
  var myDialog = document.getElementById('myDialog');
  
  // register the event at initialization
  // Option #1: On the receiver itself... (See next example for Option #2)
  myDialog.addEventListener('dismissrequest', dismissHandler);

  // at some point during runtime, the handler will be called
  // (e.g. if, for example, the user presses ESC key while focus is inside the dialog)
  function dismissHandler(e) {
  
    // cancel and close the dialog (don't forget to move focus before closing)
    closeDialog(e.receiver); // Event.receiver is a readonly property like Event.target 
    
    // then cancel the event
    e.stopPropagation(); // stop the event from bubbling.
    e.preventDefault(); // let the UA/AT know the event was intercepted successfully.

  }

</script>

1.4.2 Changing the Value of a Custom Slider

The following example uses a 'valuechangerequest' event to modify the value of a custom ARIA slider.

Example 2

<!-- Declare which IndieUI event(s) this element receives. -->
<canvas uiactions="valuechange" id="slider" role="slider" aria-valuemin="0" aria-valuemax="100" aria-valuenow="42"></canvas>

<script type="text/javascript">


  
  // register the event at initialization
  // Option #2: Using event delegation on any node (such as the body) that is higher in the DOM than the receiver element...
  document.body.addEventListener('valuechangerequest', valueChangeHandler);

  // at some point during runtime, the handler will be called
  function valueChangeHandler(e) {
    
    // Find the event receiver element
    var slider = e.receiver;
    
    // grab context info from the Event object
    var changeType = e.changeType;
    
    // update the model and display
    myApp.requestValueChangeForElement(changeType, slider);

    // cancel the event
    e.stopPropagation(); // stop the event from bubbling 
    e.preventDefault(); // let the UA/AT know the event was intercepted successfully

  }

</script>

1.5 Backwards-Compatibility

This section is non-normative.

One of the core principles behind UI Change Request Events is that they operate on a backwards-compatible, opt-in basis. In other words, the web application author has to first be aware of these events, then explicitly declare each event receiver and register an event listener, or user agents behave as they normally would.

Change request events do not cause any direct manipulation or mutation of the DOM, and do not have any 'default action' in the context of a web view. Instead, the event conveys the user's intent to the web application, and allows the web application to perform the appropriate action on behalf of the user, including making potential changes to the DOM. If a web application is authored to understand the change request event, it can cancel the event, which informs the user agent that the event has been captured and understood. If a web application does not cancel the event, the user agent may attempt fallback behavior or communicate to the user that the input has not been recognized.

2. UI Actions

User interface actions are declared as enumerated token attribute values on an element. Each value corresponds to a specific UI Request Event, and declares the web page author's ability to receive and handle each of the request events initiated by the user agent. In order to receive each request event, authors MUST also register for the event using Element.addEventListener() at this node or higher in the DOM. User agents SHOULD NOT initiate a UI Request Event when the user's point-of-regard is not inside an element with the corresponding defined action.

2.1 The uiactions IDL Attribute

The uiactions attribute of each instance of the Element interface MUST return a DOMTokenList reflecting the uiactions content attribute.

partial interface Element {
    readonly    attribute DOMTokenList uiactions;
};

2.1.1 Attributes

uiactions of type DOMTokenList, readonly
A DOM element attribute whose DOMTokenList value reflects the value of the uiactions content attribute.

This attribute is readonly b/c DOMTokenList values are modified by methods (e.g. el.uiactions.add("pan");) rather than by string assignment (e.g. NOT el.uiactions = "pan";). Need to make sure this is clear for authors.

2.2 The uiactions Content Attribute

Every element may have a uiactions attribute specified, which is necessary to define the receiver of each type of request event. The attribute, if specified, must have a value that is a set of whitespace-separated tokens representing the various actions to which the web application responds on behalf of this element. The actions that an element has assigned to it consists of all the tokens returned when the value of the uiactions attribute is split on whitespace. (Duplicates are ignored.)

User agents MUST reflect the uiactions content attribute in the uiactions IDL attribute.

Example 3

<!-- body element is event listener for all events, but event receiver only for 'undo' actions. -->
<body uiactions="undo">

  <!-- Element container for custom 'mapview' is the event receiver for 'pan' and 'zoom' actions. -->
  <div id="mapview" uiactions="pan zoom"> ... </div>

  <!-- This Dialog is the event receiver for 'dismiss' actions initiated on any lower-level event target. -->
  <dialog uiactions="dismiss"> ... </dialog>

</body>

<script type="text/javascript">
  
  // registered all of these on the body as an example of event delegation to help illustrate the difference between event
  // target (document.activeElement or other point-of-regard), receiver (element with defined actions), and listener (body)
  document.body.addEventListener('dismissrequest', handleDismiss);
  document.body.addEventListener('panrequest', handlePan);
  document.body.addEventListener('undorequest', handleUndo);
  document.body.addEventListener('zoomrequest', handleZoom);

</script>
Note

In the previous example, the 'undorequest' event may be fired any time the user's point-of-regard was inside the document . However, the 'dismissrequest' would only be fired when the user's point-of-regard was inside the dialog. Likewise, the 'panrequest' and 'zoomrequest' would only be fired when the user's point-of-regard was inside the map view.

3. UI Request Events

There is purposefully no request event for activating the default action. Authors are encouraged to use a standard click event for default actions.

Event fires on point-of-regard (document.activeElement, clicked element, or AT equivalent) if applicable, or otherwise document.body.

Event order: These events should be asynchronous, but when used in conjunction with keyboard events, we need to define where each IndieUI event fires in the chain of keydown, keyup, and keypress. Probably also need an identifier to associate each event with other related physical events: e.g. this dismissrequest event is associated with the keyboard events keydown, keyup, and keypress of the ESC key.

3.1 Interface UIRequestEvent

Separate interface from UIEvent because the @uiactions attribute will 1) affect when and where these events are fired, and 2) adds the distinction of an event receiver element (element declaring the uiactions attribute) in addition to the "target" element where the event initiates and the "listener" element where the event is registered for and handled.

The receiver attribute of each instance of the UIRequestEvent interface MUST return an EventTarget matching the DOMElement where the corresponding event's action is declared via the uiactions attribute.

[Constructor(DOMString typeArg, optional UIRequestEventInit dictUIRequestEventInit)]
interface UIRequestEvent : UIEvent {
    readonly    attribute EventTarget receiver;
};

3.1.1 Attributes

receiver of type EventTarget, readonly
In addition to the event target, each UI Request Event has a receiver element, which is declared via the uiactions content attribute on an ancestor node of the event target.

3.1.2 Determining the Event Receiver

The event receiver is determined using the following steps:

  1. For each event name literal (e.g. "dismissrequest"), determine the corresponding uiactions token (e.g. "dismiss").
  2. Starting with the event's target element, determine if the element's actions list contains the corresponding action for the event (e.g. el.uiactions.contains("dismiss")). If the current element's action list contains the corresponding uiactions token, the event target is also the event receiver.
  3. If the current element's action list does not contain the corresponding uiactions token, move up to the parent element and try again. Continue until reaching the root element. The closest ancestor to match the corresponding action token is the event receiver.
  4. If the event receiver is still undetermined upon reaching the root element, stop. There is no valid event receiver and the user agent MUST NOT initiate the event.

May also need a way to associate IndieUI events with their physical event counterparts.

[Example]
partial interface UIEvent {
  readonly attribute EventID id; // UID of current event
  readonly attribute EventList relatedEvents; // List of related events, with ID and potentially type of each event. 
  // e.g. This 'dismissrequest' event is associated with the previous 'keydown' and 'keyup' events.
}

3.1.3 UIRequestEventInit

dictionary UIRequestEventInit {
    boolean       bubbles = true;
    boolean       cancelable = true;
    AbstractView? view = null;
    long          detail = 0;
    EventTarget   receiver = null;
};
3.1.3.1 Dictionary UIRequestEventInit Members
bubbles of type boolean, defaulting to true
cancelable of type boolean, defaulting to true
detail of type long, defaulting to 0
receiver of type EventTarget, defaulting to null
view of type AbstractView, nullable, defaulting to null

3.1.4 UIRequestEvent Types

The different types of UIRequestEvents that can occur are:

Undo Request (undorequest)

Indicates the user desires to 'undo' the previous action.

May be superseded by the UndoManager interface.

  • Bubbles: Yes
  • Cancelable: Yes

Users, wanting to 'undo' a discrete action in a web application, can indicate their intent a number of ways, including pressing Control+Z on Windows or Linux, Command+Z on Mac OS X, and even by shaking some accelerometer- or gyroscope-enabled mobile devices.

Redo Request (redorequest)

Indicates the user desires to 'redo' the previously 'undone' action.

May be superseded by the UndoManager interface.

  • Bubbles: Yes
  • Cancelable: Yes

Users, wanting to 'redo' a discrete action in a web application, can indicate their intent a number of ways, including pressing Control+Shift+Z on Windows or Linux, Command+Shift+Z on Mac OS X.

Expand Request (expandrequest)

Indicates the user desires to to reveal information in a collapsed section (e.g. a disclosure widget) or branch node in a hierarchy (e.g., a tree view).

  • Bubbles: Yes
  • Cancelable: Yes
Collapse Request (collapserequest)

Indicates the user desires to hide or collapse information in an expanded section (e.g. a disclosure widget) or branch node in a hierarchy (e.g., a tree view).

  • Bubbles: Yes
  • Cancelable: Yes
Dismiss Request (dismissrequest)

Indicates the user desires 'dismiss' the current view (e.g. canceling a dialog, or closing a popup menu).

  • Bubbles: Yes
  • Cancelable: Yes

Users, wanting to 'escape from' or 'dismiss' a web application state (for example, closing a modal dialog), can indicate their intent a number of ways, most commonly by pressing Escape on keyboard-controlled operating systems. Web authors who have registered for this event should process the event to determine whether to cancel the event. If the 'dismiss' action is understood in the context of the web application, web authors should perform the appropriate action (such as closing the dialog), and cancel the event using the event object's preventDefault() method.

Delete Request (deleterequest)

Indicates the user wants to initiate a 'delete' action on the marked element or current view.

  • Bubbles: Yes
  • Cancelable: Yes

3.2 Interface UIFocusRequestEvent

Will probably need an ARIA 1.1 or 2.0 role for palette.

[Constructor(DOMString typeArg, optional UIFocusRequestEventInit dictUIFocusRequestEventInit)]
interface UIFocusRequestEvent : UIRequestEvent {
    const unsigned short UNKNOWN = 0;
    const unsigned short NAV_FIRST = 1;
    const unsigned short NAV_PREV = 2;
    const unsigned short NAV_NEXT = 3;
    const unsigned short NAV_LAST = 4;
    const unsigned short NAV_UP = 5;
    const unsigned short NAV_UP_RIGHT = 6;
    const unsigned short NAV_RIGHT = 7;
    const unsigned short NAV_DOWN_RIGHT = 8;
    const unsigned short NAV_DOWN = 9;
    const unsigned short NAV_DOWN_LEFT = 10;
    const unsigned short NAV_LEFT = 11;
    const unsigned short NAV_UP_LEFT = 12;
    readonly    attribute unsigned short focusType;
};

3.2.1 Attributes

focusType of type unsigned short, readonly

3.2.2 Constants

NAV_DOWN of type unsigned short
NAV_DOWN_LEFT of type unsigned short
NAV_DOWN_RIGHT of type unsigned short
NAV_FIRST of type unsigned short
NAV_LAST of type unsigned short
NAV_LEFT of type unsigned short
NAV_NEXT of type unsigned short
NAV_PREV of type unsigned short
NAV_RIGHT of type unsigned short
NAV_UP of type unsigned short
NAV_UP_LEFT of type unsigned short
NAV_UP_RIGHT of type unsigned short
UNKNOWN of type unsigned short

3.2.3 UIFocusRequestEventInit

dictionary UIFocusRequestEventInit {
    boolean        bubbles = true;
    boolean        cancelable = true;
    AbstractView?  view = null;
    long           detail = 0;
    EventTarget    receiver = null;
    unsigned short focusType = 0;
};
3.2.3.1 Dictionary UIFocusRequestEventInit Members
bubbles of type boolean, defaulting to true
cancelable of type boolean, defaulting to true
detail of type long, defaulting to 0
focusType of type unsigned short, defaulting to 0
Type of linear or directional focus requested, as defined in the interface constants. Defaults to 0 (UNKNOWN).
receiver of type EventTarget, defaulting to null
view of type AbstractView, nullable, defaulting to null

3.2.4 UIFocusRequestEvent Types

Todo: explain these can cover focus changes when the element to focus is not yet loaded in the DOM or yet focusable (for example, in list or table views where the entire dataset is not displayed), or non-linear focus shortcuts or overrides when linear focus is not possible (for example, jumping directly from a contenteditable region to the editing toolbar, when Tab and Shift+Tab mean other things).

The types of UIFocusRequestEvents that can occur are:

Directional Focus Request (directionalfocusrequest)

Initiated when the user agent sends a "direction focus" request to the web application. Web authors SHOULD NOT use or register for directionalfocusrequest events when standard browser focus and blur events are sufficient. Using these events unnecessarily could result is reduced performance or an other negative user experience.

  • Bubbles: Yes
  • Cancelable: Yes
  • Context Info: focusType (one of directional focus constants)
Linear Focus Request (linearfocusrequest)

Initiated when the user agent sends a "linear focus" request to the web application. Web authors SHOULD NOT use or register for linearfocusrequest events when standard browser focus and blur events are sufficient. This event type is only necessary on specialized control types such as data grids where the logical next element may not be focusable or even in the DOM until requested. Using these events unnecessarily could result is reduced performance or an other negative user experience.

  • Bubbles: Yes
  • Cancelable: Yes
  • Context Info: focusType (one of linear focus constants)
Palette Focus Request (palettefocusrequest)

Initiated when the user agent sends a "palette focus" request to the web application. Web app authors receiving this event SHOULD move focus to the first palette in the web application, or cycle focus between all available palettes. Note: palettes are sometimes referred to as non-modal dialogs or inspector windows.

  • Bubbles: Yes
  • Cancelable: Yes
Toolbar Focus Request (toolbarfocusrequest)

Initiated when the user agent sends a "toolbar focus" request to the web application. Web app authors receiving this event SHOULD move focus to the main toolbar in the web application, or cycle focus between all available toolbars.

  • Bubbles: Yes
  • Cancelable: Yes

3.3 Interface UIManipulationRequestEvent

[Constructor(DOMString typeArg, optional UIManipulationRequestEventInit dictUIManipulationRequestEventInit)]
interface UIManipulationRequestEvent : UIRequestEvent {
    readonly    attribute double? originX;
    readonly    attribute double? originY;
    readonly    attribute double  deltaX;
    readonly    attribute double  deltaY;
    readonly    attribute double  scaleFactor;
    readonly    attribute double  rotation;
};

3.3.1 Attributes

deltaX of type double, readonly
deltaY of type double, readonly
originX of type double, readonly , nullable
originY of type double, readonly , nullable
rotation of type double, readonly
scaleFactor of type double, readonly

3.3.2 UIManipulationRequestEventInit

dictionary UIManipulationRequestEventInit {
    boolean          bubbles = true;
    boolean          cancelable = true;
    AbstractView?    view = null;
    long             detail = 0;
    EventTarget      receiver = null;
    optional double? originX = null;
    optional double? originY = null;
    optional double  deltaX = 0.0;
    optional double  deltaY = 0.0;
    optional double  scaleFactor = 1.0;
    optional double  rotation = 0.0;
};
3.3.2.1 Dictionary UIManipulationRequestEventInit Members
bubbles of type boolean, defaulting to true
cancelable of type boolean, defaulting to true
deltaX of type optional double, defaulting to 0.0
The cartesian X coordinate delta, in CSS pixels.
deltaY of type optional double, defaulting to 0.0
The cartesian Y coordinate delta, in CSS pixels.
detail of type long, defaulting to 0
originX of type optional double, nullable, defaulting to null
The cartesian X coordinate origin point (if one exists), measured in CSS pixels from the left edge of element box for the receiver element.
originY of type optional double, nullable, defaulting to null
The cartesian Y coordinate origin point (if one exists), measured in CSS pixels from the top edge of element box for the receiver element.
receiver of type EventTarget, defaulting to null
rotation of type optional double, defaulting to 0.0
Rotation value, in degrees from 0. Positive values indicate a counter-clockwise rotation. Negative values indicate a clockwise rotation.
scaleFactor of type optional double, defaulting to 1.0
Scale factor, used in zoom manipulations, where 1.0 is the original scale factor. For example, a value of 2.0 or 3.0 indicates the element should enlarge to 2 or 3 times its original scale, respectively. A value of 0.5 indicates the element should decrease to one-half its original scale.
view of type AbstractView, nullable, defaulting to null

3.3.3 UIManipulationRequestEvent Types

Note

Move and Pan request events are functionally identical, but are specified individually to aid in authoring clarity when using similar concepts like 1) moving an object on a layout canvas, and 2) panning a continuous view like a map.

The types of UIManipulationRequestEvents that can occur are:

Move Request (moverequest)

Initiated when the user agent sends a move request to the web application with accompanying x/y delta values. This is used, for example, when moving an object to a new location on a layout canvas.

  • Bubbles: Yes
  • Cancelable: Yes
  • Context Info: deltaX, deltaY
Pan Request (panrequest)

Initiated when the user agent sends a pan request to the web application with accompanying x/y delta values. This is used, for example, when changing the center point while panning a map or another custom image viewer.

  • Bubbles: Yes
  • Cancelable: Yes
  • Context Info: deltaX, deltaY
Rotation Request (rotationrequest)

Initiated when the user agent sends a rotation request to the web application with accompanying origin x/y values and a rotation value in degrees.

  • Bubbles: Yes
  • Cancelable: Yes
  • Context Info: originX, originY, rotation
Note

In the case where a User Agent lacks a clear or relevant point of origin, user agents could send null values for originX and originY, or they could send x/y coordinates representing the center point of the event.receiver element.

For example, many photo manipulation applications allow users to change orientation, or rotating a photograph 90 degrees, by pressing a key combination like Option+LeftArrow or Option+RightArrow. Since this represents a keyboard only event that is unrelated to the mouse pointer location, it would be appropriate to send null values. In many cases, web applications may not require the origin x/y coordinates for rotation events even if non-null values exist.

Zoom Request (zoomrequest)

Initiated when the user agent sends a zoom request to the web application with accompanying origin x/y values and the zoom scale factor.

  • Bubbles: Yes
  • Cancelable: Yes
  • Context Info: originX, originY, scaleFactor
Note

Web authors may use originX and originY in the way they deem most appropriate for the context of their application. In most cases, web applications receiving zoomrequest events will center the UI "zoom" on the originX/originY coordinates if they are provided. If origin coordinates are not provided, such as in the case of a keyboard-only zoom event, web authors will likely center the UI "zoom" in the middle of the receiving view.

There may be a need for a combined, continuous manipulation events (e.g. Pan+Zoom simultaneously) in addition to the discrete events listed above, but specification ideas are incomplete. Currently an author could achieve the same result by listening for the series of discrete Zoom and Pan events.

3.4 Interface UIScrollRequestEvent

[Constructor(DOMString typeArg, optional UIScrollRequestEventInit dictUIScrollRequestEventInit)]
interface UIScrollRequestEvent : UIRequestEvent {
    const unsigned short DELTAS = 0;
    const unsigned short UP = 1;
    const unsigned short RIGHT = 2;
    const unsigned short DOWN = 3;
    const unsigned short LEFT = 4;
    const unsigned short PAGE_UP = 5;
    const unsigned short PAGE_RIGHT = 6;
    const unsigned short PAGE_DOWN = 7;
    const unsigned short PAGE_LEFT = 8;
    const unsigned short LIMIT_UP = 9;
    const unsigned short LIMIT_RIGHT = 10;
    const unsigned short LIMIT_DOWN = 11;
    const unsigned short LIMIT_LEFT = 12;
    readonly    attribute double?        deltaX;
    readonly    attribute double?        deltaY;
    readonly    attribute unsigned short scrollType;
};

3.4.1 Attributes

deltaX of type double, readonly , nullable
deltaY of type double, readonly , nullable
scrollType of type unsigned short, readonly

3.4.2 Constants

DELTAS of type unsigned short
Default value for scrollType indicating that scroll amount is provided as deltaX and deltaY in CSS pixels.
DOWN of type unsigned short
Equivalent to the default behavior of the DOWN key in most native scroll views.
LEFT of type unsigned short
Equivalent to the default behavior of the LEFT key in most native scroll views.
LIMIT_DOWN of type unsigned short
Equivalent to the default behavior of the END key in most native scroll views.
LIMIT_LEFT of type unsigned short
LIMIT_RIGHT of type unsigned short
LIMIT_UP of type unsigned short
Equivalent to the default behavior of the HOME key in most native scroll views.
PAGE_DOWN of type unsigned short
Equivalent to the default behavior of the PAGEDOWN key in most native scroll views.
PAGE_LEFT of type unsigned short
PAGE_RIGHT of type unsigned short
PAGE_UP of type unsigned short
Equivalent to the default behavior of the PAGEUP key in most native scroll views.
RIGHT of type unsigned short
Equivalent to the default behavior of the RIGHT key in most native scroll views.
UP of type unsigned short
Equivalent to the default behavior of the UP key in most native scroll views.

3.4.3 UIScrollRequestEventInit

dictionary UIScrollRequestEventInit {
    boolean          bubbles = true;
    boolean          cancelable = true;
    AbstractView?    view = null;
    long             detail = 0;
    EventTarget      receiver = null;
    optional double? deltaX = 0.0;
    optional double? deltaY = 0.0;
    unsigned short   scrollType = 0;
};
3.4.3.1 Dictionary UIScrollRequestEventInit Members
bubbles of type boolean, defaulting to true
cancelable of type boolean, defaulting to true
deltaX of type optional double, nullable, defaulting to 0.0
The cartesian X coordinate delta, in CSS pixels.
deltaY of type optional double, nullable, defaulting to 0.0
The cartesian Y coordinate delta, in CSS pixels.
detail of type long, defaulting to 0
receiver of type EventTarget, defaulting to null
scrollType of type unsigned short, defaulting to 0
Type of scroll requested, as defined in the interface constants. Defaults to 0 (DELTAS) which indicates deltas are provided.
view of type AbstractView, nullable, defaulting to null

3.4.4 UIScrollRequestEvent Types

The single type of UIScrollRequestEvent that can occur is:

Scroll Request (scrollrequest)

Initiated when the user agent sends a scroll request to the web application with accompanying x/y delta values or one of the other defined scrollType values. Authors SHOULD only use this event and uiaction with custom scroll views.

Need an example here and clarifying text to indicate UAs "must" either send a non-default scrollType, or non-default deltas, but not both.

  • Bubbles: Yes
  • Cancelable: Yes
  • Context Info: scrollType, deltaX, and deltaY

3.5 Interface UIValueChangeRequestEvent

[Constructor(DOMString typeArg, optional UIValueChangeRequestEventInit dictUIValueChangeRequestEventInit)]
interface UIValueChangeRequestEvent : UIRequestEvent {
    const unsigned short UNKNOWN = 0;
    const unsigned short INCREMENT = 1;
    const unsigned short INCREMENT_SMALL = 2;
    const unsigned short INCREMENT_LARGE = 3;
    const unsigned short INCREMENT_MAX = 4;
    const unsigned short DECREMENT = 5;
    const unsigned short DECREMENT_SMALL = 6;
    const unsigned short DECREMENT_LARGE = 7;
    const unsigned short DECREMENT_MIN = 8;
    readonly    attribute unsigned short changeType;
};

3.5.1 Attributes

changeType of type unsigned short, readonly

3.5.2 Constants

DECREMENT of type unsigned short
Equivalent to the default behavior of the DOWN key on most native sliders.
DECREMENT_LARGE of type unsigned short
Equivalent to the default behavior of PAGEDOWN or SHIFT+DOWN on many native sliders.
DECREMENT_MIN of type unsigned short
Equivalent to the default behavior of the HOME key on most native sliders.
DECREMENT_SMALL of type unsigned short
Equivalent to the behavior of ALT+DOWN or OPTION+DOWN on some native controls, indicating a finely tuned adjustment (e.g. -0.1% as opposed to -1%).
INCREMENT of type unsigned short
Equivalent to the default behavior of the UP key on most native sliders.
INCREMENT_LARGE of type unsigned short
Equivalent to the default behavior of PAGEUP or SHIFT+UP on many native sliders.
INCREMENT_MAX of type unsigned short
Equivalent to the default behavior of the END key on most native sliders.
INCREMENT_SMALL of type unsigned short
Equivalent to the behavior of ALT+UP or OPTION+UP on some native controls, indicating a finely tuned adjustment (e.g. +0.1% as opposed to +1%).
UNKNOWN of type unsigned short

3.5.3 UIValueChangeRequestEventInit

dictionary UIValueChangeRequestEventInit {
    boolean        bubbles = true;
    boolean        cancelable = true;
    AbstractView?  view = null;
    long           detail = 0;
    EventTarget    receiver = null;
    unsigned short changeType = 0;
};
3.5.3.1 Dictionary UIValueChangeRequestEventInit Members
bubbles of type boolean, defaulting to true
cancelable of type boolean, defaulting to true
changeType of type unsigned short, defaulting to 0
Type of change requested, as defined in the interface constants. Defaults to 0 (UNKNOWN).
detail of type long, defaulting to 0
receiver of type EventTarget, defaulting to null
view of type AbstractView, nullable, defaulting to null

3.5.4 UIValueChangeRequestEvent Types

The single type of UIValueChangeRequestEvent that can occur is:

Value Change Request (valuechangerequest)

Initiated when the user agent sends a value change request to the web application. Used on custom range controls like sliders, carousels, etc.

Web authors MUST code applications to accept all values of the changeType attribute. For example, if there is no special behavior for INCREMENT_SMALL or INCREMENT_LARGE, web applications would behave as if they had received a basic INCREMENT change type.

  • Bubbles: Yes
  • Cancelable: Yes
  • Context Info: changeType

Users, wanting to change the value of a custom range widget (e.g. sliders or carousels) in a web application, can indicate their intent a number of ways, including pressing various keys (Up, Down, Left, Right, PageUp, PageDown, Home, End) on most keyboard-controlled interfaces. User agents understanding this intent should initiate a valuechangerequest event. Web authors who have registered for this event, should process the event to determine whether to cancel the event. If the value change action is understood in the context of the web application, web authors should change the value of the associated widget by an amount determined via the changeType argument, and cancel the event using the event object's preventDefault() method.

4. Strings for DOMImplementation.hasFeature()

User agents with complete support for IndieUI Events 1.0 MUST return true when the DOMImplementation.hasFeature() method is called with the feature string "org.w3c.indieui.events" and version "1.0". User agents with partial-but-incomplete support for Indie UI 1.0 MAY return true when queried with the version string "0.0".

The previous RFC-2119 "may" is intended to prevent UAs from claiming full support too soon. Should we use 0.0, 0.9, or something else here? UAs should probably not return true for DOMImplementation.hasFeature("org.w3c.indieui.events", "1.0") until after we publish a Last Call draft.

User agents implementing specific events MUST return true when the DOMImplementation.hasFeature() method is called with a feature string matching the literal event name appended to the main IndieUI events string, such as "org.w3c.indieui.events.valuechangerequest".

A. Events List (alphabetical)

B. Normative changes since the last public working draft

C. Glossary

Assistive Technology

TBD

Marked Element(s)

TBD. Will be defined in conjunction with markrequest, which is covered by ACTION-25, and not yet in the spec.

Point-of-Regard

UIRequestEvents initiate from the element representing the point-of-regard, and are referenced in the Event object's target property.

For mainstream user agents, the point-of-regard will likely be the element under a pointer (e.g. mouse cursor) or, in the case of keyboard events, the currently focused element (e.g. document.activeElement). Assistive technologies or other alternative inputs may determine another element to be the subject of the user's attention, and initiate events from this new point-of-regard.

Reflected Attribute

Attributes whose DOM property and content attribute values remain in sync. Identical to reflected attributes in HTML.

Request Event Receiver

The closest DOM ancestor to the user's point-of-regard that declares the current event type via the uiactions content attribute or uiactions DOM attribute. The Request Event Receiver is referenced in the Event object's receiver property.

UI Request Events are not initiated by the user agent unless the following are true:

  1. The user's point of regard is on the current or descendant node of an element that declares the event receiver via @uiactions
  2. The event receiver node (or any ancestor node of the receiver) also registered as the event listener via element.addEventListener()

Some of this definition will need to be massaged and move into the normative sections above defining @uiactions.

User Agent

TBD

D. Acknowledgements

D.1 Active IndieUI Members

At the time of publishing, the following individuals were active, participating members of the IndieUI Working Group.

D.2 Contributors

The following individual(s) were previously members of the working group or otherwise active contributors.

Lachlan Hunt

D.3 Enabling funders

This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED-OSE-10-C-0067. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.