W3C home > Mailing lists > Public > public-indie-ui@w3.org > December 2012

Re: interface definitions in Events spec

From: James Craig <jcraig@apple.com>
Date: Wed, 05 Dec 2012 11:45:41 -0800
Cc: public-indie-ui@w3.org
Message-id: <47C79BD8-FDEB-4EF5-AF83-5A37CD910426@apple.com>
To: Jason White <jason@jasonjgw.net>

On Dec 5, 2012, at 1:05 AM, Jason White <jason@jasonjgw.net> wrote:

> James Craig <jcraig@apple.com> wrote:
>> The thinking was twofold:
>> 1. I believe the interfaces needed some additional parameters not available
>> in UIEvent. Are you anticipating adding a "partial interface UIEvent" for
>> these, or handling those outside of the interface? 
> I didn't notice any additional parameters in UIRequestEvent, but I might have
> missed one. The other interfaces do have additional fields, but these could be
> handled by inheriting from UIEvent and therefore specifying only the
> additional attributes and methods.

Ah, I see. Okay, I think that's reasonable given the current version of the spec, but let's consider it after the declarative attribute (TBD, but maybe @ui-actions) is added to the spec. It was a new proposal from the face-to-face, and it may affect the interface because it will 1) affect when and where these events are fired, and 2) adds the distinction of an event "receiver" element in addition to the "target" element where the event initiates and the "listener" element where the event is registered for and handled.

>> 2. Because this is a "request" event—that is, a request on behalf of the
>> user for the app to make something happen, rather than a notification that
>> something already has happened—I thought it best to keep the interface
>> separate, in case there are other unforeseen differences that need to be in
>> the spec. That said, I'm open to solving that problem when we get to it, if
>> you have a good solution that incorporates the additional needs and
>> parameters in a better way.
> That's an interesting semantic point that I didn't notice upon reading the
> draft. I would think of objects implementing these interfaces, rather, as
> events (as indications to the Web application that something has happened,
> namely that the user has issued a certain request in whatever device-specific
> way is appropriate to the context).
> These events are conceptually the same as keyboard, mouse or touch events, but
> defined more abstractly, like focus events for example. They dispatch when the
> user performs an implementation and possibly context-dependent action.
> I'm not strongly arguing for a position here, merely carrying forward the
> discussion.

There's more about this distinction here, but the informative introduction hasn't made it into the spec yet.

Received on Wednesday, 5 December 2012 19:46:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:09:15 UTC