[Bug 19771] New: Need way to determine what keys are supported on device.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19771

          Priority: P2
            Bug ID: 19771
                CC: mike@w3.org, www-dom@w3.org
          Assignee: schepers@w3.org
           Summary: Need way to determine what keys are supported on
                    device.
        QA Contact: public-webapps-bugzilla@w3.org
          Severity: enhancement
    Classification: Unclassified
                OS: All
          Reporter: glenn@skynav.com
          Hardware: PC
            Status: NEW
           Version: unspecified
         Component: DOM3 Events
           Product: WebAppsWG

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.