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

On Wed, Mar 11, 2015 at 1:02 AM, Sangwhan Moon <smoon@opera.com> wrote:
>
>
> On Tue, Mar 10, 2015 at 10:21 PM, Rick Byers <rbyers@chromium.org> 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
>> <https://docs.google.com/a/chromium.org/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit>
>> 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
sketch
<https://docs.google.com/a/chromium.org/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit>?
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 <smoon@opera.com> 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] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20219
>>>
>>>
>>> On Tue, Mar 10, 2015 at 12:47 AM, Rick Byers <rbyers@chromium.org>
>>> 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 <http://www.w3.org/TR/WebIDL/#idl-enums>, did it?  Why
>>>> didn't we use an enum?  Document.visibilityState
>>>> <http://www.w3.org/TR/page-visibility/#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
>>>> <https://docs.google.com/a/chromium.org/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit#>
>>>> .
>>>>
>>>> Rick
>>>>
>>>
>>>
>>>
>>> --
>>> Sangwhan Moon [Opera Software ASA]
>>> Software Engineer | Tokyo, Japan
>>>
>>
>>
>
>
> --
> Sangwhan Moon [Opera Software ASA]
> Software Engineer | Tokyo, Japan
>