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

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

From: Sangwhan Moon <smoon@opera.com>
Date: Tue, 10 Mar 2015 12:05:41 +0900
Message-ID: <CAFWyato4rDNUL=V_5++p3uoruvuUzmgDkZgpJ4rW6LX+ZSPWSQ@mail.gmail.com>
To: Rick Byers <rbyers@chromium.org>
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>, Mustaq Ahmed <mustaq@chromium.org>
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 03:06:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 10 March 2015 03:06:09 UTC