[Ur] event propagation

Sat May 9 18:13:40 EDT 2015

As I understand returning false is quite an old way of doing things and
preventDefault / stopPropagation is what people do.

So removing 'return false' is a right thing to do (event handler will just
return undefined when there are no 'return' at the end). But it needs to be
announced aloud since it's incompatible change and can lead to some
undesired behaviors in existing programs.

I've even made some FFI workaround for 'return false' some time ago. I
needed to select message when user click on it but with 'return false' user
couldn't click on links and videos -- they were disabled. Without 'return
false' I could remove this workaround. I'll need to test a couple dozens of
"onclick"s though but it's not a big problem.

2015-05-09 17:25 GMT+03:00 Adam Chlipala <adamc at csail.mit.edu>:

> 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.
>>
>
> _______________________________________________
> Ur mailing list
> Ur at impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20150510/24b3dd0d/attachment.html>