[whatwg] questions regarding submit event timing

[Ian Hickson]

On Mon, 2 May 2011, Hallvord R M Steen wrote:
>
> Some questions related to possibly clarifying this section: 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit
> 
> 1) What methods exactly cause the "scripted submit" flag to be set? It's 
> obviously set if you call form.submit(), but will it be set in these two 
> cases:
> 
> HTML: <form><input type="submit"></form>
> JS: form.elements[0].click()
> 
> or
> HTML: <form><input type="submit"></form>
> JS: form.elements[0].dispatchEvent( evt ) /* where evt is a 'click'
> event object  */
> 
> I believe the answer should be yes in both cases but I'm not sure if 
> it's clear from the spec.

On Mon, 2 May 2011, Glenn Maynard wrote:
> 
> The only place in the HTML5 spec itself that sets this flag is submit() 
> (http://www.whatwg.org/specs/web-apps/current-work/#dom-form-submit), 
> although other specs could also use that flag.

Indeed.


On Mon, 2 May 2011, Jonas Sicking wrote:
> 
> 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.

On Thu, 5 May 2011, Hallvord R M Steen wrote:
> 
> 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.

On Thu, 5 May 2011, Jonas Sicking wrote:
> 
> 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?

I've renamed it to "submitted from submit() method".


On Mon, 2 May 2011, Hallvord R M Steen wrote:
>
> 2) Is the event fired synchronously? (And is it fired synchronously for 
> all three cases of scripted submits mentioned above?) Again, I think the 
> answer is yes but I couldn't find this information in the spec when 
> looking for it.

On Mon, 2 May 2011, Glenn Maynard wrote:
> 
> All events in the HTML5 spec are effectively synchronous; it uses tasks 
> to get the effect of what DOM Events calls an "asynchronous event".  
> Step 6 says "fire a simple event that is cancelable named submit, at 
> form", which is strictly synchronous; if it was firing it asynchronously 
> it'd say "queue a task to fire a simple event".
> 
> (It's also possible for an entire algorithm to be running from a task, 
> in which case the event is synchronous with respect to the algorithm, 
> but the algorithm itself, including the event, is asynchronous with 
> respect to any script that triggered it.  Handling these common but more 
> complicated interactions is why this method is much clearer and more 
> powerful than the overgeneric "asynchronous event" concept.)

Indeed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'