Re: [w3c/touch-events] Spec should be explicit on whether the order of elements in TouchLists is relevant (#13)

Did some very rough and ready testing with this http://patrickhlauke.github.io/touch/tracker/multi-touch-tracker-index.html (which only uses touch events and visually shows each touch in `targetTouches`, complete with its "index" and the unique `identifier`) and current behavior seems to vary already across implementations.

While during a touch interaction (once all touches have been placed on the screen) the order of touches in the TouchList object doesn't seem to change (the index remains consistent, at least in the tested browsers) in most cases, there are some tricky variations when touches are added/removed: 

- Edge (with touch events enabled in about:flags):  when a touch is removed, order is preserved (touches with an index greater than the removed touch are "bumped to the left" in the same order to fill the gap); new touches are always added at the end of the TouchList object.

- Chrome/Win10: order is *not always* preserved when a touch is removed (the index can flip/flop for temporarily, until it settles); new touches are always added at the end of the TouchList object.

- Chrome/Android 6: order preserved when touch removed; however, new touches are *not always* added at the end (e.g. if a touch was removed during gesture, and then a new touch added, this new touch gets added at index 0 bumping all other touches "to the right" by 1).

- Firefox/Android 6: order is *not* consistently preserved (can flip randomly) when touch removed; new touches are *not always* added at the end (e.g. if a touch was removed during gesture, and then a new touch added, this new touch gets added at index 0 bumping all other touches "to the right" by 1).

Personally, I feel it would be better to write a generic note explaining that the order in which Touch objects can be found in the various TouchList objects can change arbitrarily (particularly in situations when a touch is added or removed), and that authors should not rely on it - instead, to explicitly track a touch in a multi-touch case, they should refer to the unique `identifier` associated with a touch. Happy to draft/PR something.

Thoughts?

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/touch-events/issues/13#issuecomment-205807381