On Thursday, May 5, 2011, Hallvord R M Steen <[email protected]> wrote: > (Thanks to those clarifying the sync/async event question :-)) > > 2011/5/3 Jonas Sicking <[email protected]>: >> 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
