[Ur] event propagation

Sat May 9 10:25:33 EDT 2015

I attempted a little version-control archeology to remind myself why I 
made event handlers stop propagation by default.  I made the change in 
September 2009, but, poking around mailing-list traffic at that time, I 
don't see any discussion of the issue.

What does everyone think?  What's the right default behavior for an 
event handler on a tag?  It would be possible to change all events to 
[transaction bool] instead of [transaction unit], so that the return 
value is given literally; but that sounds like awkwardness that doesn't 
pay its way for most cases.

Since stopping propagation was made the default, someone contributed 
built-functions [preventDefault] and [stopPropagation], which correspond 
to methods by those names on JavaScript event objects, in at least some 
popular browsers. Would it make sense to (1) have event handlers return 
truthy values by default (I believe Julian's patch has this effect) and 
(2) require calling [preventDefault] or [stopPropagation] to change the 
behavior?

On 05/07/2015 09:38 AM, Julian Squires wrote:
> I tried to write something like the following:
>
>   datatype s = A | B | C
>
>   fun main () =
>       s <- source A;
>       return <xml><body><form>
>         <radio{#Test}>
>           <radioOption value="A" onclick={fn _ => set s A} />
>           <radioOption value="B" onclick={fn _ => set s B} />
>           <radioOption value="C" onclick={fn _ => set s C} />
>         </radio>
>         <dyn signal={v <- signal s;
>                      return <xml><div>{[case v of A => "A"
>                                                 | B => "B"
>                                                 | C => "C"]}</div></xml>} />
>       </form></body></xml>
>
> Because the onclick event handler produced is hard-coded to return
> false, the radio buttons don't update correctly.
>
> I have applied the attached patch to my own installation to get around
> it, but I imagine this might break existing code.  It seems like one
> would want more explicit control of the return value of the event
> handler.