This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It would be useful for pure-JS forms if the script could indicate to the UA that the form should be considered submitted, e.g. for the purposes of saving data from fields. There's two obvious ways we could do this: - a kind of method like method=dialog that essentially does nothing except this. <form method=scripted onsubmit="..."> <!-- doesn't have to cancel event --> <input type=submit> </form> - an API that you call to invoke the successful-form-submission behaviour, even if you didn't submit the form: <script> function go(f) { ... f.saveFormFields(); } </script> <form onsubmit="go(this); return false"> <!-- handle implicit submission --> <input type=button onclick="go(form)"> </form> The former is far simpler. The latter has the advantage that you can invoke it when the form isn't submitted (e.g. from a "save" button), and that for back-compat you need to worry about canceling the event anyway.
Given that the target audience of this kind of feature would be UIs that are already doing some sort of work to suppress the default action (and will continue to need to do so for the foreseeable future), not needing to cancel the event's default behavior isn't much of an advantage for the declarative method (though I agree that it's simpler and probably more elegant). The central advantage of the latter method is that it doesn't actually require a form submission. As you note, there are certainly cases in which data is implicitly saved without triggering a submit event. I'd prefer to be able to handle this scenario in a reasonable way.
I think that I would also lean towards the latter syntax. I don't have numbers to quantify how often this happens, but anecdotally a fair number of sites already "submit" a form without ever calling "form.submit()" (e.g. <button onclick="scrapeFormAndSendXHR()">). As Ian points out, form.saveFormFields() seems like it fits more naturally in this case.
We could also do both and define the former in terms of the latter.
(In reply to Ian 'Hixie' Hickson from comment #3) > We could also do both and define the former in terms of the latter. That seems perfectly reasonable.
Matt, can you comment on what you think of this proposal, as an implementor?
I just sent an email[1] to the list indicating that I don't think a new API is necessary given how easy it is to use form submission instead and the benefits that come with that. (In reply to Garrett Casto from comment #2) > …anecdotally a fair number of > sites already "submit" a form without ever calling "form.submit()" (e.g. > <button onclick="scrapeFormAndSendXHR()">). Do they have a good reason to be doing so? i.e. why can't they cancel the submission instead? If there isn't a good reason, then what makes you think they're going to learn about this new API when they could have used form submission all along? Another thing to keep in mind is that UAs may not actually want to save all values in text inputs. In Firefox we don't save form history for fields which have the default value (i.e. not changed my the user). [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-May/254233.html
I agree with Matthew. Authors can just rely on the regular submission mechanism and cancel submission if they need to. Basically, #1 above but without the dedicated value, just canceling instead.
Though on the thead, Garrett raised the point that that leaves no way to distinguish a failed submission from a successful one. That's an argument in favour of #1 above (a way to do form submission that does nothing). Is action="javascript:" sufficient instead, maybe?
I'm closing this. action="javascript:" (with no script body) has the right semantics, works today from what I can tell, and doesn't look so bad.
Note that I'm attempting to address some of this "nice to have" stuff with a more comprehensive mechanism allowing interaction between a website and a user agent's password store: https://mikewest.github.io/credentialmanagement/spec/