'Retargeting steps' run at wrong time

[smaug----]

All the retargeting should happen before event is being handled, since event handling may change the underlying DOM and that way affect to the retargeting.

Touch event specific bug, w3c/touch-events#92

[annevk]

This also affects w3c/uievents#157.

cc @hayatoito @rniwa @travisleithead

[annevk]

Here's an idea:

• Instead of relatedTarget on events and event paths we rename that to relatedTargets (plural). It's a list of null/EventTarget objects.
• Events with a relatedTarget member set it to a list containing a single item. Touch events set it to a list containing all the targets of the various Touch objects (this is a fixed list).
• Then we make all the operations operating on relatedTarget work on a sequence instead.

I think this works since relatedTarget and touch events are mutually exclusive. Even if they weren't though, this could still work by relatedTarget just occupying a special slot.

The complexity here is that UI Events and Touch Events need to initialize relatedTargets properly, but that's all the complexity they need to worry about. Everything else can be done by the DOM Standard.

(I was initially thinking of handling Touch targets separately, but that just leads to a lot of duplication, so I think the above approach is preferable if it indeed works.)

cc @whatwg/components

[annevk]

Ah, this does require event objects that support related targets to implement "initialize related target steps" which is passed path's relatedTargets. That way we can update what gets exposed. That still seems reasonable.

[annevk]

Actually, even that isn't necessary if they just make those attributes reflect the internal relatedTargets slot. That is a little special for events and might require some constructor special casing though.