W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2011

[whatwg] HTMLForms: Implicit Submission with {display:none} button

From: Kaustubh Atrawalkar <kaustubh@motorola.com>
Date: Thu, 13 Oct 2011 12:03:05 +0530
Message-ID: <CANw-Mg8mEWCTpJr4K1rrGFviD54dqExn4_O7re_zMyRV4Nh+5w@mail.gmail.com>
On Mon, Sep 26, 2011 at 2:36 AM, Glenn Maynard <glenn at zewt.org> wrote:

> On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>>  The current Trident/WebKit behavior has a nice side-effect to (without
>> scripts) require a visible submit button to enable implicit form submission.
>>
>
> I don't find that nice.  As a user, it's very annoying when implicit form
> submission doesn't work for some obscure reason (like not having a submit
> control), forcing me to use the mouse instead of it behaving like any other
> form.  It makes the UI inconsistent and unpredictable.
>
> Also, the single-text-input-with-no-submit-button case doesn't follow the
> above.
>
> The "without scripts" is also a fatal caveat.  Users can't be expected to
> understand things like "you can press enter to submit the form if you see a
> browser-native submit button, but not if the button is actually scripted
> markup".
>
> In principle, *all* forms should allow implicit submit, unless the site
> explicitly doesn't want it (scripted autosave dialogs) or the UA doesn't
> support it.  That ship sailed years ago, but the visibility of the submit
> button shouldn't enter into it.
>
>
Should this be made to for all browser compliance and browser to allow
implicit submission irrespective of visibility of submit button? A web-dev
can always stop this by either disabling the submit button or through
script. Browser can give control back to onsubmit handler on enter key press
if there is enabled submit button.
Received on Wednesday, 12 October 2011 23:33:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:37 UTC