With elm 0.19 we were supposed to get control over sync or async processing of events. However, due to issues with how the elm virtual dom handles events, this change has been partially cancelled / postponed.
Now, if and only if an event stops propagation, it will trigger a sync DOM repaint. The reason for this strange behavior is explained in issue elm/virtual-dom#125. So even if stopping propagation leads to less surprising events, it should not be the default in elm-pointer-events due to performance concerns for high frequency events such as move events (mouse, touch, pointer, …).
So I’m going to change this in the package. The question I have is should I only change this for the high frequency events (mouse move, touch move, dragging, etc.) at the risk of consistency, or make it default for all events, at the risk of some surprises (events propagation can be weird, especially with layout arranging libraries like elm-ui).
Have you previously encountered strange behaviors due to not stopping propagation? Any experience welcomed here or in elm-pointer-events#15.
I don’t think I know enough about propagation to answer that, but I do know that I have seen strange bugs in relation to high-frequency and asynchronous events. That is, where multiple events are triggered against the same Model version, meaning that some of the events are potentially ‘stale’.
I don’t think that problem can be solved by making those events synchronous, due to performance as you say above. I tend to solve it by making Model a state machine, and effectively ignoring any stale events by seeing them as having occurred outside of an allowed state.
If you cannot have ‘no propagation’ with ‘asynchronous’, I guess the only way forward would be to allow propagation, and see what strange things happen as a result. In that case, I think you would have a genuine reason to request exploration of the “Future Possibility” described in issue 125.
Yes I also think that’s the best way of dealing with this. Move events (mouse, touch or pointer) may happen at higher frequencies than frame rate so forcing a DOM computation is not good. Better let it be until next scheduled animation frame and vdom update, as it does usually, and treat events with care in the update loop.
I think I only needed to stop propagation when doing some drop down menus. Clicking on below items would close then reopen the menu because I had put them in children items of the button to open the menu. This could be avoided of course, but using stop propagation (and forcing dom computation) for those “click” cases is fine.
I have not used elm-pointer-events specifically, but In general, I’ve always tried to avoid using stop propagation as much as possible. The motivation for this is that it may hide information needed for other UI interactions on the page. The most common example of this is a tooltip/popup interface activated by a click which should disappear when the user clicks anywhere outside of the tooltip. The common (only?) way to detect those external clicks is to listen for click events on the document, and then check to see if they originated inside the tooltip. This breaks if the click outside of the tooltip is on an element that stops propagation.
It may be possible to workaround this by using the capture phase, although I seem to remember there being other issues with that approach. That said, it has been a while since I implemented something like this. Maybe it is less of an issue now due to browser changes.