<div dir="ltr">As I understand returning false is quite an old way of doing things and preventDefault / stopPropagation is what people do.<div><br></div><div>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.</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-05-09 17:25 GMT+03:00 Adam Chlipala <span dir="ltr"><<a href="mailto:adamc@csail.mit.edu" target="_blank">adamc@csail.mit.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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?<div><div class="h5"><br>
<br>
On 05/07/2015 09:38 AM, Julian Squires wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I tried to write something like the following:<br>
<br>
datatype s = A | B | C<br>
<br>
fun main () =<br>
s <- source A;<br>
return <xml><body><form><br>
<radio{#Test}><br>
<radioOption value="A" onclick={fn _ => set s A} /><br>
<radioOption value="B" onclick={fn _ => set s B} /><br>
<radioOption value="C" onclick={fn _ => set s C} /><br>
</radio><br>
<dyn signal={v <- signal s;<br>
return <xml><div>{[case v of A => "A"<br>
| B => "B"<br>
| C => "C"]}</div></xml>} /><br>
</form></body></xml><br>
<br>
Because the onclick event handler produced is hard-coded to return<br>
false, the radio buttons don't update correctly.<br>
<br>
I have applied the attached patch to my own installation to get around<br>
it, but I imagine this might break existing code. It seems like one<br>
would want more explicit control of the return value of the event<br>
handler.<br>
</blockquote>
<br></div></div>
_______________________________________________<br>
Ur mailing list<br>
<a href="mailto:Ur@impredicative.com" target="_blank">Ur@impredicative.com</a><br>
<a href="http://www.impredicative.com/cgi-bin/mailman/listinfo/ur" target="_blank">http://www.impredicative.com/cgi-bin/mailman/listinfo/ur</a><br>
</blockquote></div><br></div>