[whatwg] questions regarding submit event timing

[Jonas Sicking]

On Thursday, May 5, 2011, Hallvord R M Steen <hallvors at gmail.com> wrote:
> (Thanks to those clarifying the sync/async event question  :-))
>
> 2011/5/3 Jonas Sicking <jonas at sicking.cc>:
>> Isn't the purpose of this flag mostly backwards compatibility, but
>> otherwise a fairly awkward feature. If so, it seems like we should
>> limit its scope as much as possible, both to make implementation
>> easier, and to make the forms API otherwise as simple as we can.
>
> It seems to have two purposes:
> 1) avoid doing form validation on form.submit()
> Definitely a backwards compatibility feature, and one that yours truly
> probably caused by complaining when form.submit() was specified to
> throw an exception when the form didn't validate. This broke websites
> left, right and center when implemented in Opera.
>
> 2) Avoid firing a submit event.
> What is more intuitive for button.click() or a synthetic click event
> on the button - submit event firing? I guess so, in that case the spec
> as-is is OK though it's a bit counter-intuitive that other scripted
> ways to submit a form than .submit() don't set the scripted-submit
> flag.

>From a behavioral perspective I think it's most intuitive that the
events fire and that validation occurs. That way calling .click()
behaves as if the user clicked.

However I agree that a name like "scripted-submit" could be
interpreted to mean that it should include other things than calls to
.submit.

Maybe renaming the flag would make the spec more intuitive?

/ Jonas