Re: Clarification for UI Request events (why no "activate"?)

On 05/02/2013 05:43 PM, James Craig wrote:
> On May 2, 2013, at 5:05 PM, Eitan Isaacson <eitan@mozilla.com>
> wrote:
> 
>> On 05/02/2013 03:36 PM, James Craig wrote:
>> 
>>> See this 2009 thread about DOMActivate in favor of click. 
>>> http://lists.w3.org/Archives/Public/public-forms/2009Jul/0008.html
>>>
>>>
>>> 
Maciej wrote:
>>>> Unfortunately, Web compatibility requires sending a "click"
>>>> event for non-mouse-driven activations. In particular, it is a
>>>> common practice to give an <a> element or an <input
>>>> type="button"> element an onclick attribute and the page author
>>>> expects it to trigger even for keyboard activation. This
>>>> practice precedes the existence of the DOMActivate event and
>>>> remains common. Authors almost never use a DOMActivate handler
>>>> instead.
>> 
>> Thanks for the link, I guess this is the discussion I was looking
>> for earlier. It puts a lot of this in perspective. I still think
>> there is a need for a mouse agnostic activate.
>> 
>>> I think you can still use DOMActivate if truly necessary, but
>>> most web apps use click handlers instead. Doug will be able to
>>> speak to this point better.
>> 
>> DOMActivate was deprecated. And it is definitely humbling to think
>> about re-introducing something similar. But that is the goal of
>> this spec.
> 
> 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.

Cheers,
  Eitan.

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