ACTION-53 (Was: Clarification for UI Request events (why no "activate"?))

On May 2, 2013, at 6:42 PM, Eitan Isaacson <eitan@mozilla.com> wrote:

> On 05/02/2013 05:43 PM, James Craig wrote:
>> 
>> Are you asking that IndieUI include an "activate" event (identical to
>> DOMActivate) that has a default action like click, or are you asking
>> for an "activaterequest" event that has no default action if the web
>> app didn't catch and handle it?
> 
> The history of DOMActivate is definitely off-putting when it comes to
> trying that again.
> 
>> I think "activaterequest" fits within the format of IndieUI events,
>> but I'm having trouble understanding why this would be preferable to
>> click.
>> 
>> Would you be suggesting that authors use this instead of click in
>> most cases? If so, I'm very worried that this would unduly complicate
>> the well-understood and predictable practice of using click handlers.
> 
> My revised opinion is no. click should be enough, since that is what
> most people know and will do anyway. But in the absence of a click
> listener, a requestactivate should be available. An example:
> 
> The iPhone has a slide to unlock widget on the lockscreen. It does not
> get activated by simple click/tap, the user needs to slide their finger
> along the track from left to right. But when VoiceOver is on, the
> default activation gesture works and unlocks the screen.
> 
> So the caveat I would add to activaterequest is that it is *not* needed
> when a simple click listener will do.
> 
>> If that's not what you're proposing, I would be much more open to
>> adding this event with the stipulation that authors SHOULD use click
>> in most circumstances.
> 
> Correct. I'm convinced that is the most pragmatic way forward.

Okay, you've convinced me too. ;-) 

ACTION-53: Add ~"activate request" event to augment default action trigger when "click" handlers are inappropriate.
https://www.w3.org/WAI/IndieUI/track/actions/53

Received on Friday, 3 May 2013 01:53:42 UTC