Re: Comments: User Interface Independence for accessible Rich Internet Applications

>From a browser implementation perspective, I believe the latter design
(abstract events dispatched after device-specific events go unhandled)
would be better and easier for us (chromium). +rjkroege who is our expert
and can comment in more detail.

Also, we will want some abstract events to be 'un-cancellable', and so the
latter design is essential.  In particular, it's critical to modern
touch-enabled browsers to be able to scroll a page / element on a separate
thread (using GPU acceleration) without blocking on JavaScript.  So if an
abstract scroll event came first, and we had to wait to see if the page did
preventDefault() before we knew if we could scroll, it would make
consistently smooth scrolling impossible.

Rick

On Thu, Aug 9, 2012 at 1:30 AM, Jason White <jason@jasonjgw.net> wrote:

> This submission, which antedates current work, suggests interfaces
> pertinent to
> both IndieUI Events and User Contexts. Some aspects of the proposal are
> beyond
> the scope of this working group, for instance the functions to access an
> assistive technology cursor and to create speech output.
>
> My initial comments concern the event-related aspect of the proposal. The
> details of interfaces and event types will be developed in due course in
> response to use cases. There are, however, wider issues to consider as
> well.
>
> The proposal establishes the following behaviour for events that it
> defines:
>
> 1. An abstract user interface event is dispatched and may be handled by
> registered listeners.
>
> 2. If it handles an abstract event successfully, the Web application calls
> preventDefault() to suppress the default action.
>
> 3. Otherwise, the user-agent may dispatch the underlying device-specific
> events (e.g., keyboard events).
>
> Effectively, the Web application only receives the underlying
> device-specific
> events if the associated abstract events are not cancelled and the UA
> happens
> to forward the device-specific events.
>
> The following alternative design would be more consistent with the DOM
> Level 3
> Events specification, for example the relationship between mouseup,
> mousedown
> and click events.
>
> 1. The UA assigns default actions to certain device-specific UI events and
> event sequences; these actions dispatch the associated abstract events.
>
> 2. Consequently, the Web application receives both the device-specific
> events
> corresponding to a user's interaction and the abstract events defined in
> IndieUI events.
>
> 3. If a device-specific event is cancelled, then (per DOM Level 3 Events),
> the
> default action, namely the dispatching of the associated abstract event,
> is not
> performed.
>
> 4. If there is no device-specific event defined in the user-agent's API
> corresponding to a user's input (for instance, no event associated with
> speech
> input), then only the abstract event is dispatched.
>
> There are trade-offs to be made in both designs, and these alternatives are
> not exhausive. My purpose is merely to place the issues before the working
> group.
>
> I found it helpful in reviewing the submission that specific interfaces
> have
> been put forward in the proposal. These will contribute to our work,
> especially in connection with events.
>
>
>