Proposal for UIEvent "role" property

[garykac]

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25655

caitp 2014-05-10 23:13:45 UTC

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 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.

Comment 1 Masataka Yakura 2014-05-11 13:34:45 UTC

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 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.

Comment 2 caitp 2014-05-11 16:25:19 UTC

I've been looking over the IndieUI proposals, and I think it covers some of this, but not all of it, and not necessarily very well.

Adding new event types seems like a non-solution which complicates things further. Instead, annotating existing events with a role for their particular UI interaction, and providing a way to listen to events filtered based on the annotated interaction, seems much simpler, and easier to polyfill.

But I suppose discussions about that would be better suited for the IndieUI WG.

But it's good that there's at least an interest in working with high-level interactions rather than low-level inputs, so that's great.

Comment 3 Travis Leithead [MSFT] 2014-05-12 18:58:47 UTC

(In reply to caitp from comment #2)

I've been looking over the IndieUI proposals, and I think it covers some of
this, but not all of it, and not necessarily very well.

Adding new event types seems like a non-solution which complicates things
further. Instead, annotating existing events with a role for their
particular UI interaction, and providing a way to listen to events filtered
based on the annotated interaction, seems much simpler, and easier to
polyfill.

But I suppose discussions about that would be better suited for the IndieUI
WG.

But it's good that there's at least an interest in working with high-level
interactions rather than low-level inputs, so that's great.

Thanks! There may be something we can add in to some events to improve the situation.

Note: moving to UI Events path which is where future work and feature requests are being collected at the moment.

[garykac]

d656fdc fixes bug 21 in the uievents-key repo, not this one.