This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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.
(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.
Now tracking as: https://github.com/w3c/uievents/issues/21