Re: User interaction events

On Apr 17, 2014, at 3:11 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Apr 16, 2014 at 9:09 PM, James Craig <jcraig@apple.com> wrote:
>> On Wed, Apr 16, 2014, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> Not really, they're basically adding a layer of difficulty in figuring out what it all means later.
>> 
>> I don't think "adding a layer of difficulty" is a fair synopsis.
> 
> Something like Indie UI does seem like a good thing to have. However,
> given how well we have documented fundamental concepts such as hit
> testing, mouse events, focus, scrolling, and now touch and pointer
> events, adding a layer of abstraction seems troublesome.

Perhaps it would be beneficial to explain your intention of terms like "difficulty" and "troublesome". Difficult for whom? Troublesome because? These statements are vague and difficult to interpret. If by troublesome you mean "difficult to specify", I think that is probably true, but I don't believe that difficulty negates the necessity of being able to abstract events. 

Interaction patterns should be both programmatically determinable and controllable, for the sake of all users (including those who use uncommon user interfaces not covered by DOM or Pointer events), and even for the sake of programs programs like automation scripts. If we can also use this as an opportunity to make authoring easier, that's a worthwhile goal, regardless of the difficulty in specification.

> Without a solid grasp of the foundation, it's unclear where these
> should be dispatched relative to the others, how setting an event's
> canceled flag affects processing, etc. Akin to adding something like
> <template> to HTML before we knew the design of its parser.

If by "these" you mean IndieUI events, that's why it's a first public working draft; send feedback if you have some. There are several editorial notes related to your questions already in the spec. You may have missed them when you read the draft. For example:

"""
Event order: These events should be asynchronous, but when used in conjunction with keyboard events, we need to define where each IndieUI event fires in the chain of keydown, keyup, and keypress. Probably also need an identifier to associate each event with other related physical events: e.g. This dismissrequest event is associated with the keyboard events keydown, keyup, and keypress of the esc key.
"""

Another relevant editorial note in a different section of the draft is:

"""
May also need a way to associate IndieUI events with their physical event counterparts.

[Example]
partial interface UIEvent {
  readonly attribute EventID id; // UID of current event
  readonly attribute EventList relatedEvents; // List of related events, with ID and potentially type of each event. 
  // This "dismissrequest" event is associated with the previous "keydown" and "keyup" events.
}
"""

The loose idea here is that a web application could selectively choose to respond to or cancel related events based on some aspect of the current or some previous related event. There would be no default processing effect (all events would fire), but web apps could selectively ignore the related *subsequent* physical events if they have handled a previous semantic event. 

Obviously there is complexity involved—particularly when some physical event comes in before a semantic event could be determinable—but it's not an unsolvable challenge for specification or implementation. It's a huge win for users and web authors, so it's worth the effort.

> So as to Domenic's question of how we should deal with UI events... We
> need to document the core algorithms. Given some system "cursor" task,
> you adjust for the browsing context's viewport, you hit test on the
> render tree, you get the corresponding element in the DOM, you
> calculate the various event property values, you dispatch one or more
> events as appropriate. If that's too abstract, consider whether or not
> mousemove and mouseover in
> http://www.w3.org/TR/2013/WD-DOM-Level-3-Events-20131105/#h5_events-mouseevent-event-order
> can happen in the same task. Now combine that with pointer events. Or
> consider interaction of click and focus.

The "EventsList relatedEvents" idea would benefit that scenario as well. Many times authors hide focus with outline:0 or prevent focus altogether because they don't like the visual effect of a focus that is a result of a mouse click. If authors could detect the focus event was a result of a previous mouse event rather than a keyboard event, they could make a more effectively usable interface.

James

Received on Thursday, 17 April 2014 21:15:46 UTC