Re: [Events] UI Triggers for IndieUI Events 1.0

On May 23, 2014, at 8:50 PM, Jason White <jason@jasonjgw.net> wrote:

> Responding to several of Rich's excellent comments below.
> Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
> 
>> Section 5.1.1
>> "May also need a way to associate IndieUI events with their physical event
>> counterparts."
>> 
>> Regarding the above comment, if we do this it should be non-normative and
>> it will need to be platform dependent. We could have an authoring practices
>> guide for this - similar to what we did for keyboard for aria. I don't
>> think we want to normatively state the exact key bindings, etc. for a
>> platform as the platform owner may wish to change conventions.
>> 
> 
> I agree. However, I understood the note here to be suggesting a function that
> would return a representation of the physical events associated with an
> IndieUI abstract event. This wouldn't allow the Web application to change the
> association but only to read it, for example to populate help text in a user
> interface.

Sorry for the confusion. This is not exactly referring to what either of you have suggested. Let me give an example of "related" events.

When a user presses the Tab key to move focus from one item to the next, several events are triggered, in the following order.
1. keydown
2. keyup
3. keypress (some platforms suppress keypress on special keys like Arrows and Tab)
4. blur (on the previously focused element)
5. focus (on the newly focused element)

The author has the opportunity to call preventDefault() any point along this series of events, but there is no reliable way to detect that the keyboard events are what triggered the following blur and focus. If you're only listening for focus, you get a "relatedTarget" property that points to the previously focused element, but you can't necessarily detect that a textfield focus was caused by a mouse event, keyboard event, or some other physical event. There's no evidence to associate it with the previous physical event. (If you're using delegation to track *all* events, there is some circumstantial evidence related to timing and event order, but it's unreliable.)

This editorial note is suggesting that UIEvent or Event be extended with an identifier key one could use to associate the current event object with the event objects of related events. The idea is not fully fleshed out.

James

Received on Wednesday, 28 May 2014 23:39:29 UTC