[webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications

[Ojan Vafai]

I don't think calling these "Request" events fits with the rest of the web
platform. Essentially, these are events that fire before some action occurs
and gives the web developer the opportunity to cancel that action. The
precedence in web events is to call those before* events. So, instead of
having an UndoRequest event, we'd have a BeforeUndo event. These events seem
completely consistent with other before* events in their expected behavior.

To be clear, I'm not trying to block you moving forward with this. I
completely agree these use-cases need to be met. I just want to make sure we
do something that is consistent with the rest of the platform and meets as
many use cases as possible.

Other responses inline...

On Tue, Nov 2, 2010 at 3:01 PM, James Craig <jcraig at apple.com> wrote:

> On Nov 2, 2010, at 12:48 PM, Ojan Vafai wrote:
>
> I still don't see why beforeInput would not be sufficient. It might be more
> clear if you enumerated the list of things you expect to have
> UIRequestEvents for.
>
>
> There are several examples in the proposal, including:
>
> Users, wanting to change the value of a custom range widget (ARIA slider,
> ARIA media progressbar, etc.) in a web application, can indicate their
> intent a number of ways, including pressing various keys
> (up, down, left, right, pageup, pagedown, home, end) on most
> keyboard-controlled interfaces, and through gestures on many touch-enabled
> interfaces. User agents understanding this intent should initiate
> a ValueChangeRequest event. Web authors who have registered for this event,
> should process the event to determine whether to cancel the event. If the
> value change action is understood in the context of the web application, web
> authors should change the value of the associated widget by an amount
> determined via the changeType argument, and cancel the event using the event
> object's ---() method. If the event is not cancelled by the web author, user
> agents may pass the literal interaction event to the web application; in
> this case, in the form of a keypress event.
>

I think one area of confusion is that I don't get why UIScrollRequestEvent,
UIValueChangeRequestEvent and DOMAttributeChangeRequestEvent inherit from
UIRequestEvent. The event types currently listed under UIRequestEvent all
seem like they'd be appropriate for beforeInput. I understand
that UIScrollRequestEvent, UIValueChangeRequestEvent and
DOMAttributeChangeRequestEvent might not be met be replaceable by
beforeInput (scroll clearly isn't!).

> As I stated in the bug tracker comments, the W3C DOM and PF working groups
> discussed this, and the outcome was to work on a standalone specification as
> a joint effort of the two groups. The initial document editors will likely
> be Doug Schepers (W3C staff contact for www-dom) and me. From the
> teleconference discussions, these will be an add-on to DOM 3 Events and/or
> ARIA 1.0, because both of those documents are currently in Last Call. The
> only major change to the proposal so far that we're discussing a new method
> to the Event object (perhaps 'suppressEvents' or 'suppressRelatedEvents') so
> that we don't have to cancel the event by overloading the original use of
> the preventDefault method.
>
> What's the difference between preventDefault and suppressEvents?
>
>
> preventDefault only prevents the default action of the current event.
> supressEvents would allow the author to inform the user agent that any
> remaining events for the same user interaction are no longer relevant. For
> example, if the user pressed either Delete key and the application
> intercepted the DeleteRequest event, it could call Event.suppressEvents()
> (or whatever we call it) to indicate that the related events (keydown,
> keyup, keypress) are no longer needed, and the user agent should not fire
> them.
>

The issue here is that these are meta events that could correspond to
different default actions? I think it would be fine to spec it such that the
default action depends on what the user did. For example, if the user hits
the delete key, the default action would be the keydown. preventDefault on
the DeleteRequest would prevent the keydown and thus they keypress/keyup. If
the user deletes from the menu, then the default action is just the delete
itself.

Web developers are already confused enough by the combination of
preventDefault and stopPropagation. I don't think this situation calls for
adding a third method. We can just hide the complexity in the speccing of
the default actions for each event.

> Also, earlier in this thread, you said that you don't know of anything that
> requires these events to be synchronous, but that seems to contradict
> James's point above and the patch in question fires the events
> synchronously. The spec text all also implies that the event fires, then
> application has the chance to prevent it and then the action happens.
> So, unless I'm misreading, the events need to be synchronous and fire before
> the associated action occurs.
>
> All events are like that. For example, a 'click' event on a link can
> prevent the web view from navigating to the link's href URL. The event
> sequence needs to happen in order and the action within the web view should
> wait for the event to complete, but I don't believe this needs to be
> synchronous between the browser and a web view running in a separate thread.
>

One of us misunderstood Adam's point. Not sure which. :) My concern is that
they are synchronous within the JS code. That is a common source of crashes
and security vulnerabilities. Not all events are like this. For many async
events, the action happens and the event is just posted to the event loop.
It's a notification to the web developer that something happened. My
intuition is that you can't make many of these events async without losing
the ability of the web developers to prevent the default action, which kills
the usefulness of the event.

> To be clear, my concern so far has just been about UIRequestEvent, which
> seems to overlap 100% with beforeInput.
>
> Everything I've read about input events implies they are limited to form
> inputs. UIRequestEvent, for example, could be used to undo the last action,
> such as "undo close file", or "undo move message to trash", where the input
> events could not.
>

They currently fire for text controls and contentEditable areas. I think it
would be reasonable to extend it to fire in non-editable, focusable elements
as well. It's not unlike keydown firing on non-editable, but focusable
elements.

> -DOMAttributeChangeRequestEvent: The spec text is pretty vague as to what
> should and shouldn't fire this. With the spec text, without the
> note/example, this event sounds a lot like DOMAttrModified and has all the
> associated problems. There's a note that claims it doesn't have the same
> problems, but I don't see how that's the case. I'd be happier with this if
> it were explicitly about ARIA attributes, i.e. AriaChangeEvent.
>
> I agree that this should be speced, but I don't think it should be limited
> to ARIA.
>

How is this event any different than DOMAttrModified? The spec claims it
doesn't have the problems that DOMAttrModified has, but I don't see how
that's the case.

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101104/bff63044/attachment.html>