RESOLUTION: have a relatedEvent to point to the UI event that caused a DI event to be fired

[johanneswilm]

Not sure, but this was related to issues #19 and #25. As I remember it, we had the resolution, and then after that we discovered that it possibly couldn't be used for the purpose of solving issues #19 and #25 anyway. But I guess the resolution still stands, right?

[fredck]

May I add another naming option: sourceEvent.

[Reinmar]

relatedEvent may be semantically more accurate as there are actions which are a result of many events (Ctrl+C gives two keydowns).

[fredck]

I'm sorry @Reinmar but IMHO, if you take semantics in consideration, it is quite the opposite. "Source" is definitely a better word to point to somethings that results on something else. So "this" event is the result of the "source" event.

"Related" instead, could even work for this as well, but is much more unclear because there can be several different kinds of "relations" between the events, which are not "this is the result of that". It can be "that is the result of this", "that happened together with this", "that is similar to this", etc.

In the other hand, trying to explain something else, you pointed out a problem that needs to be clarified. You say that the relatedEvent/sourceEvent is not limited to a single "Event". This means that it should be "Events" instead, pointing to a collection. Is that right?

[johanneswilm]

The main point of this exercise is to have a way to tell if some features of the new spec are not present in a browser. This is important for trying to polyfill some of them and for creating editors that work on older versions of browsers as well, at least that's what we initially thought when we agreed to this resolution.

A little later, @rniwa expressed some doubts, so that we decided to work on these problems once we have some implementation experiences (see #78 ).

[johanneswilm]

This issue was moved to w3c/input-events#27