- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 29 Jul 2011 00:24:49 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 28 July 2011 17:24:49 UTC