UI Events

Table of Contents

• 1. Conformance
• 2. Goals
• 3. Keyboard Events
  • 3.1 Interface KeyboardEvent
    • 3.1.1 Attributes
    • 3.1.2 Methods
• A. References
  • A.1 Normative references

1. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].

All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.

Requirements phrased in the imperative as part of algorithms(such as "strip any leading space characters" or "return false and terminate these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

When a method or an attribute is said to call another method or attribute, the user agent must invoke its internal API for that attribute or method so that e.g. the author can't change the behavior by overriding attributes or methods with custom properties or functions in ECMAScript.

Unless otherwise stated, string comparisons are done in a case-sensitive manner.

2. Goals

UI Events builds on the event model defined in DOM Level 3 Events (and also DOM4). Features in scope for this specification are:

• Additional Keyboard event properties to allow for physical key location scenarios

3. Keyboard Events

This section extends the KeyboardEvent interface defined in DOM Level 3 by adding methods for querying the keyboard state without requiring a Keyboard event to be dispatched, and by providing locale information during the dispatch of a Keyboard event.

partial interface KeyboardEvent : UIEvent {
    static DOMString queryKeyCap (DOMString code, optional DOMString locale);
    readonly    attribute DOMString locale;
    static DOMString queryLocale ();
};

queryKeyCap('KeyA') => 'a' Default locale is 'en-US'
queryKeyCap('KeyA', 'en-US') => 'a'
queryKeyCap('KeyA', 'fr-FR') => 'q'
queryKeyCap('Digit2', 'en-US') => '2'
queryKeyCap('Digit2', 'fr-FR') => 'é' ('\u00e9')
queryKeyCap('IntlRo', 'en-US') => 'Undefined' Key doesn't exist in US keyboard
queryKeyCap('IntlRo', 'ja-JP') => 'ろ' ('\u308d')
queryKeyCap('Quote', 'nl-US') => '´' ('\u0301') Combining accent
queryKeyCap('Quote', 'ru-RU') => 'э' ('\u042d')
queryKeyCap('Backquote', 'en-US') => '`'
queryKeyCap('Backquote', 'ja-JP') => 'Backquote' Non-printable Halfwidth/Fullwidth Mode key
queryKeyCap('Space') => 'Space' Non-printable
queryKeyCap('ShiftLeft') => 'ShiftLeft' Non-printable
                

queryKeyCap('KeyA', queryLocale())