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

RE: pointerType extensibility

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Mon, 4 Mar 2013 00:49:54 +0000
To: Rick Byers <rbyers@google.com>, Brandon Wallace <brandon.wallace@yahoo.com>
CC: François REMY <francois.remy.dev@outlook.com>, Pointer Events WG <public-pointer-events@w3.org>
Message-ID: <c6fef7d8f046486399c983e97dfff91a@BN1PR03MB021.namprd03.prod.outlook.com>
> I do agree that we're probably best off leaving things as is for V1 and tackling this extensibility problem when we have a concrete example and a larger body of code to try to be compatible with.

Agree.

From: Rick Byers [mailto:rbyers@google.com]
Sent: Tuesday, February 19, 2013 5:42 PM
To: Brandon Wallace
Cc: François REMY; Pointer Events WG
Subject: Re: pointerType extensibility

On Tue, Feb 19, 2013 at 8:08 AM, Brandon Wallace <brandon.wallace@yahoo.com<mailto:brandon.wallace@yahoo.com>> wrote:
> Agreed - as you say the separate bits are better in this respect.  But I doubt any future device would choose to do this since the impact on compatibility would be inconsistent and hard to predict (would now depend on what order existing code checked for the previously mutually-exclusive choices).
If that is a concern, then why not keep it as a single "pointerType" property that guarantees mutually exclusive choices and is easy to work with?  When a new device needs to be supported, then a new subclass of PointerEvent could be created for events coming from that device and any code that cares could check for it.

Is there value in making authors write:

  if (ev instanceof TouchPointerEvent) { ... }
  else if (ev instanceof StylusPointerEvent) { ... }
  else ...

instead of letting them choose between:

  if (ev.pointerType === TOUCH) { ... }
  else if (ev.pointerType === STYLUS) { ... }
  else ...

or

  switch (ev.pointerType) {
  case TOUCH: ...
  case STYLUS: ...
  }

or even:

  handler = { TOUCH: ..., STYLUS: ..., ... };
  (handler[ev,pointerType] || defaultHandler)(ev);

I'm also thinking of libraries like jQuery that wrap the native event object within their own custom event object.  Such libraries would either need to do the instanceof tests and set their own "pointerType" property on their event object, or client code would be reduced to reaching through to the original event object:


  if (ev.originalEvent instanceof TouchPointerEvent) { ... }

Is there actual value in eliminating the pointerType property in favor of multiple properties or OO inheritance to justify the additional effort for authors?

I think the only value would be in having one consistent type identification mechanism, as opposed to two (one for the initial set of pointer types, and some other mechanism for backwards compatible extensibility).

As I've mentioned, I don't think this is the end of the world, so given the debate here, I do agree that we're probably best off leaving things as is for V1 and tackling this extensibility problem when we have a concrete example and a larger body of code to try to be compatible with.

Rick
Received on Monday, 4 March 2013 00:51:12 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:17:04 GMT