[Bug 25655] New: Proposal for UIEvent "role" property

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

            Bug ID: 25655
           Summary: Proposal for UIEvent "role" property
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM3 Events
          Assignee: travil@microsoft.com
          Reporter: caitpotter88@gmail.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org

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 on the CC list for the bug.

Received on Saturday, 10 May 2014 23:13:46 UTC