Navid Zolghadr
Navid Zolghadr
> now I see what you mean. Right, there isn't way to do that. Main thread could always post a message to the relevant worker to ask it to call...
> Because it is considered a bad API design. And MessagePort doesn't have such magical behavior on addEventListener either. (internally browsers of course optimize out dispatching various events if there...
> I guess that works if we don't want to queue events, but if we do, similarly to MessagePort, then some kind of start() is needed. Can you elaborate a...
I see now what you are saying. That was not at least our initial intention. Particularly because when the EventPort object is created we don't know what events this is...
> Sure, but that is very racy. With queuing you can guarantee that the final target gets all the events. I see. But this sort of raciness already exists today...
cc @flackr @mustaqahmed
Tries to fix #6.
@smaug---- This patch needs a lot more work to do. At the very least we need to first address the targeting issue in html spec so I can better defined...
@mustaqahmed FYI > Why is it said that the `Element` interface is extended? Shouldn't it be the whole `EventTarget` one? > Some will certainly want to listen for Window's `resize`...
> I envisioned overscroll events being about rubber banding within a given scrollable area (sending scroll event with negative offsets is not very web-compatible) This is the intention. The sign...