Re: Why isn't pointer-type an enum?

On Wed, Mar 11, 2015 at 1:02 AM, Sangwhan Moon <> wrote:
> On Tue, Mar 10, 2015 at 10:21 PM, Rick Byers <> wrote:
>> Thanks Sangwhan.  I'm remembering more of the discussion here.  I was
>> thinking enums are just as extensible by the browsers, but IIRC the
>> scenario we were interested in here was JS libraries extending browser PE
>> support with new pointerType values.  I've added an open issue with some of
>> these details for my proposed InputDevice.deviceClass
>> <>
>> API.
>> Is an "open-ended string enum" a thing today?
> Probably not. We mentioned in the spec that we may add normative
> information on possible types, which sounds pretty much like a open ended
> string enum if we ever do so though.

Right.  I suppose we could get in the habit of defining enum types and then
use a union with DOMString in the API.  Eg:

enum PointerType { "mouse", "touch", "pen" };
attribute readonly (PointerType or DOMString) pointerType;

It would be nice to make it clear to readers, tools, compilers, etc. that
we expect the common case to be a value in the enum.

I've been constantly wondering about exposing capabilities/restrictions
> rather than trying to provide the device type - in the case of a product
> I'm involved in we provide a virtual mouse cursor with 1) support for only
> a left button, 2) but with no way to keep the button depressed, 3) no way
> to know if the button has been released, and has a 4) has really rough
> granularity (moves in units of 10 pixels). But on another controller that
> controls the virtual mouse, 1) the button can be kept depressed, 2)
> possible to know when the button has been released, and 3) has accurate
> movement.
> (The former is a IR remote with a D-pad and the latter is a wireless
> controller with analog directional input.)
> I would really like to expose this information to the content authors so
> they can decide what to do in case they have a UI that needs long presses
> or dragging, so it can be adapted. As it is, I don't know of any good ways
> to do this.

Interesting.  Perhaps you want to suggest APIs to add to my InputDevice API
Francois Remy has already commented that pointerGranularity should be in
CSS PX units, rather than a constant matching the 'pointer' MQ definition.

> In the implementation I think we either have an enum (which means the ctor
>> will throw if you pass any string not in the enumeration) or a DOMString.
>> So I'm having trouble imagining what exactly something in between these
>> would look like (that's different from what the spec has today).
>> Thanks,
>>    Rick
>> On Mon, Mar 9, 2015 at 11:05 PM, Sangwhan Moon <> wrote:
>>> There was discussion on using booleans is[NameOfInputDevice] on the
>>> list, but that didn't go anywhere.
>>> (...which I think is a terrible idea.)
>>> It's extremely unlikely that it pre-dated the addition of enums in
>>> WebIDL, as that was introduced in 2011/12/21;
>>> [1] the reason why it was left open-ended is for flexibility wrt vendor
>>> extensions and polyfills. (String enums were
>>> mentioned by Olli when this discussion happened.)
>>> Setting that aside, even for standard JS implementations if the strings
>>> are a known set of variants sounds like
>>> a possibility for optimization. Personally, I think the spec should
>>> define well-known possibilities and define it
>>> in a "open-ended string enum" instead of leaving it the way it is.
>>> [1]
>>> On Tue, Mar 10, 2015 at 12:47 AM, Rick Byers <>
>>> wrote:
>>>> I forget the discussion that went into changing pointerType from an
>>>> 'int' to a 'DOMString', but I don't think it pre-dated the addition of enumerations
>>>> to WebIDL <>, did it?  Why
>>>> didn't we use an enum?  Document.visibilityState
>>>> <> is defined to
>>>> be an enum.
>>>> I wonder to what extent this matters in practice.  Obviously it's super
>>>> valuable for non-JS bindings, but I'm not sure how important those are in
>>>> practice.  Will JS extensions like asm.js be able to do additional
>>>> optimizations on enums they can't do on bare DOMStrings?
>>>> Again, I'm asking because of my InputDevice proposal
>>>> <>
>>>> .
>>>> Rick
>>> --
>>> Sangwhan Moon [Opera Software ASA]
>>> Software Engineer | Tokyo, Japan
> --
> Sangwhan Moon [Opera Software ASA]
> Software Engineer | Tokyo, Japan

Received on Wednesday, 11 March 2015 13:00:03 UTC