W3C home > Mailing lists > Public > public-pointer-events@w3.org > January to March 2015

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

From: Rick Byers <rbyers@chromium.org>
Date: Tue, 10 Mar 2015 09:21:11 -0400
Message-ID: <CAFUtAY_PTBHUyJnZoYWKdohHkAen7g9m3xq_aPrkLOCYrpEbgA@mail.gmail.com>
To: Sangwhan Moon <smoon@opera.com>
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>, Mustaq Ahmed <mustaq@chromium.org>
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

Is an "open-ended string enum" a thing today?  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).


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
Received on Tuesday, 10 March 2015 13:21:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 10 March 2015 13:21:58 UTC