[Bug 25655] Proposal for UIEvent "role" property

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25655

Masataka Yakura <myakura.web@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |myakura.web@gmail.com

--- Comment #1 from Masataka Yakura <myakura.web@gmail.com> ---
I think most of the use cases you describe are coverd by IndieUI Events.

IndieUI: Events 1.0
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html

Requirements for IndieUI: Events 1.0 and IndieUI: User Context 1.0
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-requirements.html

(In reply to caitp from comment #0)
> A modest proposal:
> 
> We have UIEvents, which should typically represent user interactions. These
> interactions get described in more detail in subclasses, such as MouseEvent,
> where some representation of the clicked button and coordinates are provided.
> 
> What I propose is that events are optionally given a "role", designating
> their UI interaction.
> 
> For instance, if I swipe a touch screen, I might want to know that the
> requested user interaction is "scroll" throughout the page.
> 
> If I right-click on an element with a mouse configured for a typical
> right-handed person, I might want to know that the interaction's role should
> eventually open a context menu (and so, might have a role of "contextmenu")
> 
> If I left-click on an element with a mouse configured for a typical
> right-handed person, I might want to know that the interaction's role should
> typically be "navigation" or "selection" depending on the type of element
> being clicked.
> 
> I don't think this would be terribly difficult for vendors to implement,
> should be relatively easy to polyfill based on properties like current
> MouseEvent.button, or similar.
> 
> I also think this kind of information would be much easier to understand
> when developing a web application, rather than sorting out what type of
> interaction is expected based on numeric properties which behave differently
> across user agents.
> 
> So, I don't know for sure if this is a good design, but to me, it seems more
> useful than being merely provided something like multitouch finger counting
> or mouse buttons assigned to integers which are prone to change.
> 
> It could eventually be taken a step further to allow some nice declarative
> mechanism for changing the role a particular event should have, like I might
> say <canvas mousewheel-role="zoom"> or something.
> 
> A couple of default interaction roles I would see being useful include:
> 
> - navigate
> - submit
> - select / deselect (in terms of checking or unchecking a checkbox or
> select-multiple, or changing the selection of a select-one)
> - zoom
> - scroll
> - collapse
> - contextmenu
> - next / previous (in terms of tab-ordering)
> - drag / drop
> 
> There are bound to be useful ones that I've missed, but I think it's worth
> considering something like this for either DOM level 3 or DOM level 4,
> because it should allow people to worry about higher-level interactions, and
> worry less about low-level details when they don't need them.
> 
> For a simple example, suppose I am using the history API in my client-side
> application, and I have a catch-all click event handler which is used to
> handle navigation with the history API:
> 
> ```
> localFrame.addEventListener("click", function(event) {
>   // ignore non-navigation roles
>   if (event.role !== "navigate") return;
> 
>   // do the rest of the work
>   if (resolveTemplateAndLoad(event.target.href))
>     history.pushState(event.target.href, someData);
> });
> ```
> 
> To take this a step further, it would be cool to be able to just listen for
> specific interaction roles, rather than listening for a specific event. This
> is because an interaction might take many different forms. I could scroll a
> page with a mousewheel or arrow keys, or by using the scrollbar. I could
> navigate to a new page by pressing enter or space on the currently focused
> item. So that form of API might look more like this:
> 
> ```
> // Suppose a hash fragment following an event name were said to mean "listen
> // only to events filtered by the specific role" --- It might step on DOM
> // event names currently, but namespaced events are usually being handled
> // differently, so it would probably be fine. Just an example, though!
> localFrame.addEventListener("#navigate", function(event) {
>   var href = event.target.href;
>   if (resolveTemplateAndLoad(href))
>     history.pushState(href, someData);
> });
> ```
> 
> Listening for events of a specific role might be harder to polyfill, but it
> would simplify a lot of client-side code, and I could see it being highly
> useful for app developers.
> 
> I'm interested in hearing what people think about this, it seems like
> something which could be fleshed out and implemented fairly easily. Maybe it
> doesn't belong in DOM level 3, but it would be really cool if we could agree
> on a way to do this nicely, and because of this, it would be great to hear
> if anyone is interested in something like that.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Sunday, 11 May 2014 13:34:46 UTC