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