search

w3c / input-events

Input Events
https://w3c.github.io/input-events/
Other
23 stars 16 forks source link

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

Open johanneswilm opened 7 years ago

johanneswilm commented 7 years ago

From @johanneswilm on August 25, 2015 14:43

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?

Copied from original issue: w3c/editing#82

johanneswilm commented 7 years ago

From @fredck on August 25, 2015 16:22

May I add another naming option: sourceEvent.

johanneswilm commented 7 years ago

From @Reinmar on August 25, 2015 20:10

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

johanneswilm commented 7 years ago

From @fredck on September 3, 2015 8:37

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 commented 7 years ago

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