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

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.

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.


> 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