Re: Standardize Buttons For TV-Web Remotes?

I agree with Glenn. I think adding a convention for prefixing custom key names is appropriate. It could be as simple as a note that vendors should devise a prefix. For example, if Microsoft were to add a custom key, then we might consider prefixing it with "ms".

What you don't want is for two vendors to devise colliding non-standardized key names for different keys. Then web apps may potentially respond to the wrong type of input.

I think any such note, however, would be non-normative. So we could do this during Last Call.

-Jacob

From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com?Subject=Re%3A%20Standardize%20Buttons%20For%20TV-Web%20Remotes%3F&In-Reply-To=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E&References=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E>>
Date: Wed, 25 May 2011 10:34:51 -0600
Message-ID: <BANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg@mail.gmail.com>
To: Doug Schepers <schepers@w3.org<mailto:schepers@w3.org?Subject=Re%3A%20Standardize%20Buttons%20For%20TV-Web%20Remotes%3F&In-Reply-To=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E&References=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E>>
Cc: Giuseppe Pascale <giuseppep@opera.com<mailto:giuseppep@opera.com?Subject=Re%3A%20Standardize%20Buttons%20For%20TV-Web%20Remotes%3F&In-Reply-To=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E&References=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E>>, W3C Web and TV <public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org?Subject=Re%3A%20Standardize%20Buttons%20For%20TV-Web%20Remotes%3F&In-Reply-To=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E&References=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E>>, "www-dom@w3.org<mailto:www-dom@w3.org?Subject=Re%3A%20Standardize%20Buttons%20For%20TV-Web%20Remotes%3F&In-Reply-To=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E&References=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E>" <www-dom@w3.org<mailto:www-dom@w3.org?Subject=Re%3A%20Standardize%20Buttons%20For%20TV-Web%20Remotes%3F&In-Reply-To=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E&References=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E>>

It is simply a matter of best practices to define normative conventions for

avoiding collisions when arbitrary parties can create names. That is why we

have .com, .org, etc in domain names; that is why Unicode has a private use

area and doesn't allow users to define character codes outside such area.

Java has a convention for ensuring non-collision of package names.

Furthermore, you don't want a third party creating a name and then in the

future you want to revise the standard to include a standard definition that

would use or reuse such a private name.



If you don't want to define a convention to permit avoiding collisions

between 3rd parties, at least define a convention that all private uses must

employ in order to distinguish from standard use. In CSS, property names

that start with '-' (HYPHEN) are considered private uses; in MIME types,

sub-types that start with "x-" are considered private use.



Now is the time to define a convention, and not later when private uses

impose constraints on new standard uses.



Regards,

Glenn



On Wed, May 25, 2011 at 10:11 AM, Doug Schepers <schepers@w3.org<mailto:schepers@w3.org?Subject=Re%3A%20Standardize%20Buttons%20For%20TV-Web%20Remotes%3F&In-Reply-To=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E&References=%253CBANLkTinzp5bQUEdTfJffnYgdUrVyTvx8wg%40mail.gmail.com%253E>> wrote:



> Hi, Glenn-

>

> Glenn Adams wrote (on 5/25/11 12:20 AM):

>

>  Thanks, this looks good. My only remaining concern is in regards to

>> implementation defined key values. The definition:

>>

>> [[

>> If there is no appropriate key value in the key values set, then a key

>> value must be devised. The key value should be as human friendly as

>> possible and must not contain whitespace characters. The value must be

>> composed only of characters in the ranges \u0030..\u0039,

>> \u0041..\u005A, or \u0061..\u007A, and must begin with a character in

>> the range \u0041..\u005A.

>> ]]

>>

>> is not adequate to prevent name collisions between custom definitions.

>> Some normative convention is needed to prevent collisions.

>>

>

> What conflicts do you anticipate?

>

> Even if there are keys on different devices that have the same values,

> webapps can still interpret the pressing of those keys in whatever way works

> best for that application; this is the intent of the key value feature.

>

> The main goal of listing key values explicitly is to promote convergence,

> not to differentiate between implementations.  I am very reluctant to add a

> convention that promotes the proliferation, rather than reduction and

> coordination, of new key values.  While such things are useful for certain

> types of extensions (new events, for example), I don't think they will be

> useful in this case, because they aren't associated with functionality

> exposed to webapps... they are only the indication that a particular button

> or key was pressed, and don't trigger any specific webapp feature (other

> than what the webapp itself "assigns" to that key value, via script).

>

> In any case, I believe that this is a comment that could be addressed in

> Last Call, because it does not introduce any normative changes to

> implementations.  Unless you see this as an issue that blocks us moving to

> Last Call, I believe the most prudent course of action is for us to do so.

>

>

> Regards-

> -Doug Schepers

> W3C Team Contact, SVG, WebApps, and Web Events WGs

>