HTMLForms: Implicit Submission with {display:none} button

[Kaustubh Atrawalkar-4]

Hi,
There is an issue regarding form submit button which is little unclear from
the specs mentioned in here http://www.whatwg.org/specs/web-apps/cu ...
submission
If the form has submit button with display property as none, will that form
should be implicitly submitted on pressing enter key? This works in Opera &
Firefox but does not work in IE & Safari as of now. What is the expected
behavior for this?

Thanks & Regards
- Kaustubh Atrawalkar

[Ian Hickson]

On Fri, 23 Sep 2011, Kaustubh Atrawalkar wrote:
>
> There is an issue regarding form submit button which is little unclear
> from the specs [...]
>
> If the form has submit button with display property as none, will that
> form should be implicitly submitted on pressing enter key? This works in
> Opera & Firefox but does not work in IE & Safari as of now. What is the
> expected behavior for this?

The strict answer is that it's up to the browsers; the spec allows
browsers to do whatever they think is appropriate per their platform's
conventions. So both behaviours are compliant.

The guidelines in the spec do not say anything about the behaviour being
different for elements that are display:none or otherwise hidden, though,
so I don't see any reason to consider the visibility of a button in making
the decision as to which button is the default.

HTH.

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

[Kaustubh Atrawalkar-4]

>
> >
> > If the form has submit button with display property as none, will that
> > form should be implicitly submitted on pressing enter key? This works in
> > Opera & Firefox but does not work in IE & Safari as of now. What is the
> > expected behavior for this?
>
> The strict answer is that it's up to the browsers; the spec allows
> browsers to do whatever they think is appropriate per their platform's
> conventions. So both behaviours are compliant.
>
> But then this might result in website compliance issue. A website having

username, password field with hidden submit button expecting to login on
enter key using forms implicit submission will work on FF & Opera but may
not work on IE & Safari.


> The guidelines in the spec do not say anything about the behaviour being
> different for elements that are display:none or otherwise hidden, though,
> so I don't see any reason to consider the visibility of a button in making
> the decision as to which button is the default.
>
> Second to your opinion, on the last line of the specs paragraph it says -
"If the form has no submit button, then the implicit submission mechanism
must just submit the form element from the form element itself."
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission


- Kaustubh

[Ryosuke Niwa-2]

On Fri, Sep 23, 2011 at 10:10 PM, Kaustubh Atrawalkar <kaustubh@...

> wrote:
>
>  > > If the form has submit button with display property as none, will that
> > > form should be implicitly submitted on pressing enter key? This works
> in
> > > Opera & Firefox but does not work in IE & Safari as of now. What is the
> > > expected behavior for this?
> >
> > The strict answer is that it's up to the browsers; the spec allows
> > browsers to do whatever they think is appropriate per their platform's
> > conventions. So both behaviours are compliant.
>
> But then this might result in website compliance issue. A website having
> username, password field with hidden submit button expecting to login on
> enter key using forms implicit submission will work on FF & Opera but may
> not work on IE & Safari.
>

WebKit's behavior is very confusing here. It does implicit submission in the
following conditions:

   - One text fields
   - Two text fields
   - One text field with one visible submit button
   - Two text fields with one visible submit button
   - Two text fields with one visibility:hidden submit button
   - One text field with one display:none submit button

However, it doesn't submit when we have:

   - Two text fields with one display:none submit button

Given that WebKit implicitly submits form even in the presence of a visible
submit button or an invisible submit button (visibility: hidden, or display:
none with exactly one text field), I don't see why we should avoid implicit
submission only when there are multiple form controls and a display:none
submit button.

- Ryosuke

[Ryosuke Niwa-2]

FYI, I checked Firefox 5's & Internet Explorer 9's behaviors as well.

IE9 does implicit submission in the following conditions:

   - One text field
   - One text field with one visible submit button
   - One text field with one display:none submit button
   - Two text fields with one visible submit button

It does not do implicit submissio in the following conditions:

   - Two text fields
   - Two text fields with one visibility:hidden submit button
   - Two text fields with one display:none submit button

Basically, IE9 only does implicit submission when there is exactly one text
field (you can have checkbox, hidden, etc...) or there is a visible button
(i.e. not diplay: none nor visibility: hidden).

Firefox 5 does implicit submission in the following conditions:

   - One text field
   - One text field with one visible submit button
   - One text field with one display:none submit button
   - Two text fields with one visible submit button
   - Two text fields with one visibility:hidden submit button
   - Two text fields with one display:none submit button

It does not do implicit submissio in the following conditions:

   - Two text fields

In summary, Firefox special cases one text field (can have checkbox, hidden,
etc...) like MSIE and requires a submit button with more than two text
fields regardless of presence of visibility: hidden or display: none.

[Ryosuke Niwa-2]

On Sat, Sep 24, 2011 at 9:47 AM, Ryosuke Niwa <rniwa@...> wrote:
>
> WebKit's behavior is very confusing here. It does implicit submission in
> the following conditions:
>
>    - One text fields
>    - Two text fields
>
>
Correction. WebKit does NOT do implicit submision for two text fields when
there are no submit buttons.

- Ryosuke

[Dimitri Glazkov-2]

Hi folks -- I wrote a fairly comprehensive test suite to capture al
this a while back:
http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/implicit-submission.html

Hope it helps!

:DG<

On Sat, Sep 24, 2011 at 1:52 PM, Ryosuke Niwa <rniwa@...> wrote:

> On Sat, Sep 24, 2011 at 9:47 AM, Ryosuke Niwa <rniwa@...> wrote:
>>
>> WebKit's behavior is very confusing here. It does implicit submission in
>> the following conditions:
>>
>>    - One text fields
>>    - Two text fields
>>
>>
> Correction. WebKit does NOT do implicit submision for two text fields when
> there are no submit buttons.
>
> - Ryosuke
>

[Glenn Maynard]

On Fri, Sep 23, 2011 at 2:52 PM, Ian Hickson <ian@...> wrote:
> The strict answer is that it's up to the browsers; the spec allows
> browsers to do whatever they think is appropriate per their platform's
> conventions. So both behaviours are compliant.

Nothing in "4.10.22.2 Implicit submission" seems to allow implicit
submission to vary based on whether a submit button is displayed or not...

(It also explicitly says that if implicit submit is supported but there's no
submit button in the form, the implicit submit must still happen.  That
doesn't sound like it could be followed, since lots of pages are probably
depending on the absence of a submit button suppressing implicit submit.
That's just backwards-compatibility, not platform conventions, though.)

On Sat, Sep 24, 2011 at 12:47 PM, Ryosuke Niwa <rniwa@...> wrote:

> However, it doesn't submit when we have:
>
>   - Two text fields with one display:none submit button
>
...
>

Another outlier: Android's WebKit, at least in 2.3.5, seems to always allow
user submit when editing a text input, via the "Go" button in the input
method, regardless of any submit buttons or their state.

IE9 does implicit submission in the following conditions:
>   - Two text fields with one visible submit button
>
> It does not do implicit submissio in the following conditions:
>   - Two text fields with one visibility:hidden submit button
>

This makes the least sense of all to me.  visibility: hidden shouldn't have
a side-effect like this.

On Sat, Sep 24, 2011 at 4:59 PM, Dimitri Glazkov <dglazkov@...>wrote:

> Hi folks -- I wrote a fairly comprehensive test suite to capture al
> this a while back:
>
> http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/implicit-submission.html
>

I adjusted this to work in other browsers and ran it in a few of them, after
adding some display: none and visibility: none cases:

http://zewt.org/~glenn/test-form-submission/
http://zewt.org/~glenn/test-form-submission/table.html

I had to make it run without data: to work around IE9.  These were run in
Windows; I suppose they may behave differently in Linux and OSX.  I didn't
spend the time to convince browsers to cache everything, so it'll be a
little slow (roundtrips per test).

--
Glenn Maynard

[Ryosuke Niwa-2]

On Sat, Sep 24, 2011 at 4:55 PM, Glenn Maynard <glenn@...> wrote:

> On Sat, Sep 24, 2011 at 12:47 PM, Ryosuke Niwa <rniwa@...> wrote:
>
>> However, it doesn't submit when we have:
>>
>>   - Two text fields with one display:none submit button
>>
> ...
>>
>
> Another outlier: Android's WebKit, at least in 2.3.5, seems to always allow
> user submit when editing a text input, via the "Go" button in the input
> method, regardless of any submit buttons or their state.
>
> IE9 does implicit submission in the following conditions:
>>   - Two text fields with one visible submit button
>>
>>
>> It does not do implicit submissio in the following conditions:
>>   - Two text fields with one visibility:hidden submit button
>>
>
> This makes the least sense of all to me.  visibility: hidden shouldn't have
> a side-effect like this.

Why? From user's perspective, not having submit button, having a submit
button with display: none, having a submit button with visibility: hidden
all look the same.

- Ryosuke

[Kaustubh Atrawalkar-4]

On Sun, Sep 25, 2011 at 5:25 AM, Glenn Maynard <glenn@...> wrote:

> On Fri, Sep 23, 2011 at 2:52 PM, Ian Hickson <ian@...> wrote:
> > The strict answer is that it's up to the browsers; the spec allows
> > browsers to do whatever they think is appropriate per their platform's
> > conventions. So both behaviours are compliant.
>
> Nothing in "4.10.22.2 Implicit submission" seems to allow implicit
> submission to vary based on whether a submit button is displayed or not...
>
> (It also explicitly says that if implicit submit is supported but there's
> no submit button in the form, the implicit submit must still happen.  That
> doesn't sound like it could be followed, since lots of pages are probably
> depending on the absence of a submit button suppressing implicit submit.
> That's just backwards-compatibility, not platform conventions, though.)
>
>

My perspective would be absence of submit button (with either
visibility:hidden OR display:none) would give user to create more enhanced
pages that will allow implicit submission like just username & password hit
enter and done and not having mandatory for Sign In button. (just a use
case)

>
> On Sat, Sep 24, 2011 at 12:47 PM, Ryosuke Niwa <rniwa@...> wrote:
>
>> However, it doesn't submit when we have:
>>
>>   - Two text fields with one display:none submit button
>>
> ...
>>
>
> Another outlier: Android's WebKit, at least in 2.3.5, seems to always allow
> user submit when editing a text input, via the "Go" button in the input
> method, regardless of any submit buttons or their state.
>
>

Yes, this reminds me more use case for tablets/mobiles where use need to
scroll the page and click on the Submit button instead he can just use the
Go button on the input may be.


> IE9 does implicit submission in the following conditions:
>>   - Two text fields with one visible submit button
>>
>>
>>
Just to add more analysis
Opera - Does Implicit submission in following cases -
* One text field
* One text field with one visible submit button
* One text field with one display:none submit button
* Two text fields with one visible submit button
* Two text fields with one visibility:hidden submit button
* Two text fields with one display:none submit button

Only in following case it does not -
* Two text fields

http://www.w3schools.com/browsers/browsers_stats.asp
Just to consider market shares of browsers - Increasing share of Firefox
(more than 40%) and decreasing share of IE (less than 25%) & also for
Mobiles & Tablets there is Opera Mini which is increasing.

[Glenn Maynard]

On Sun, Sep 25, 2011 at 1:39 AM, Ryosuke Niwa <rniwa@...> wrote:

> This makes the least sense of all to me.  visibility: hidden shouldn't have
> a side-effect like this.
>
> Why? From user's perspective, not having submit button, having a submit
> button with display: none, having a submit button with visibility: hidden
> all look the same.
>

This is an authoring question, not a user one; either the page's author
intends the form to be submittable or he doesn't.  Having visibility: hidden
affect this is even more surprising to me as an author than display: none.

Of course, display: none having an impact here is strange, too.  The
stylesheet shouldn't have this sort of behavioral side-effect.  Both of
these are weird exceptions, and happen only in IE and WebKit.  Definite
agreement with fixing WebKit to line up with FF/Opera in case #7.

--
Glenn Maynard

[Ryosuke Niwa-2]

On Sun, Sep 25, 2011 at 7:49 AM, Glenn Maynard <glenn@...> wrote:

> This is an authoring question, not a user one; either the page's author
> intends the form to be submittable or he doesn't.  Having visibility: hidden
> affect this is even more surprising to me as an author than display: none.
>

Why is this authoring question? As an user, I'd like to know whether
pressing enter in my text field triggers implicit submission or not.

Of course, display: none having an impact here is strange, too.  The
> stylesheet shouldn't have this sort of behavioral side-effect. Both of these
> are weird exceptions, and happen only in IE and WebKit.  Definite agreement
> with fixing WebKit to line up with FF/Opera in case #7.
>

Given the combined market share of Trident and WebKit, I'm not convinced we
can safely change our behavior without causing compatibility issues.

- Ryosuke

[Glenn Maynard]

On Sun, Sep 25, 2011 at 11:46 AM, Ryosuke Niwa <rniwa@...> wrote:

> On Sun, Sep 25, 2011 at 7:49 AM, Glenn Maynard <glenn@...> wrote:
>
>> This is an authoring question, not a user one; either the page's author
>> intends the form to be submittable or he doesn't.  Having visibility: hidden
>> affect this is even more surprising to me as an author than display: none.
>>
>
> Why is this authoring question? As an user, I'd like to know whether
> pressing enter in my text field triggers implicit submission or not.
>

How is that related to the presence or lack of a submit button?  In most
cases there's no correlation.  Where there is one, it's inconsistent,
because authors work around the lack of autosubmit by implementing it
manually; and even when they don't it's still inconsistent, with the strange
dependency on the number of inputs.  (Including hidden ones; because of
this, enabling CSRF form tags in a framework actually changes the UI of
forms.)

It's an authoring question whether the form is one which is submittable, or
one which is, for example, saved automatically on each change, such as some
preference pages.

--
Glenn Maynard

[Ryosuke Niwa-2]

On Sat, Sep 24, 2011 at 11:06 PM, Kaustubh Atrawalkar <kaustubh@...
> wrote:
>
> My perspective would be absence of submit button (with either
> visibility:hidden OR display:none) would give user to create more enhanced
> pages that will allow implicit submission like just username & password hit
> enter and done and not having mandatory for Sign In button. (just a use
> case)
>

Authors can already do this by injecting script although I'd argue that such
an UI is not "enhanced" at all because users may not know pressing enter
result in form submission.

I personally find implicit form submission to be annoying, and always wished
I could disable it (also backspace triggering backward navigation).

Another outlier: Android's WebKit, at least in 2.3.5, seems to always allow
>> user submit when editing a text input, via the "Go" button in the input
>> method, regardless of any submit buttons or their state.
>>
>
> Yes, this reminds me more use case for tablets/mobiles where use need to
> scroll the page and click on the Submit button instead he can just use the
> Go button on the input may be.
>

This seems like a great example for why each platform/UA wants to behave
differently.

- Ryosuke

[Kaustubh Atrawalkar-4]

On Sun, Sep 25, 2011 at 10:10 PM, Ryosuke Niwa <rniwa@...> wrote:

> On Sat, Sep 24, 2011 at 11:06 PM, Kaustubh Atrawalkar <
> kaustubh@...> wrote:
>>
>> My perspective would be absence of submit button (with either
>> visibility:hidden OR display:none) would give user to create more enhanced
>> pages that will allow implicit submission like just username & password hit
>> enter and done and not having mandatory for Sign In button. (just a use
>> case)
>>
>
> Authors can already do this by injecting script although I'd argue that
> such an UI is not "enhanced" at all because users may not know pressing
> enter result in form submission.
>
>

Yes, but author can just reduce his scripting by using default behavior
provided by the browser engine. I agree that user may not know pressing
enter results in general form submission, but in case of search he does.
Just we can make it generic instead of just for one/two input elements.

- Kaustubh

[Glenn Maynard]

On Sun, Sep 25, 2011 at 12:51 PM, Kaustubh Atrawalkar <kaustubh@...
> wrote:

> Yes, but author can just reduce his scripting by using default behavior
> provided by the browser engine. I agree that user may not know pressing
> enter results in general form submission, but in case of search he does.
> Just we can make it generic instead of just for one/two input elements.
>

That would have been nice, but there's already interop here: in all four
browsers I tested, two text inputs with no submit button never implicitly
submits.  No browser vendor would change that and break what little
consistency there is, and web compatibility would likely veto it anyway.

See http://zewt.org/~glenn/test-form-submission/table.html, column 4.

But ironing out the bizarre corner cases (eg. columns 7, 8) would be nice,
if compatibility will allow it.

--
Glenn Maynard

[Ryosuke Niwa-2]

On Sun, Sep 25, 2011 at 9:51 AM, Kaustubh Atrawalkar
<kaustubh@...>wrote:

>
> On Sun, Sep 25, 2011 at 10:10 PM, Ryosuke Niwa <rniwa@...> wrote:
>
>> On Sat, Sep 24, 2011 at 11:06 PM, Kaustubh Atrawalkar <
>> kaustubh@...> wrote:
>>>
>>> My perspective would be absence of submit button (with either
>>> visibility:hidden OR display:none) would give user to create more enhanced
>>> pages that will allow implicit submission like just username & password hit
>>> enter and done and not having mandatory for Sign In button. (just a use
>>> case)
>>>
>>
>> Authors can already do this by injecting script although I'd argue that
>> such an UI is not "enhanced" at all because users may not know pressing
>> enter result in form submission.
>>
>>
> Yes, but author can just reduce his scripting by using default behavior
> provided by the browser engine. I agree that user may not know pressing
> enter results in general form submission, but in case of search he does.
> Just we can make it generic instead of just for one/two input elements.
>

I haven't seen a search engine that requires two text fields by default. And
implicit submission already works on all browsers when there is exactly one
text field.

The current Trident/WebKit behavior has a nice side-effect to (without
scripts) require a visible submit button to enable implicit form submission.

- Ryosuke

[Boris Zbarsky]

On 9/24/11 4:45 PM, Ryosuke Niwa wrote:

> Basically, IE9 only does implicit submission when there is exactly one text
> field (you can have checkbox, hidden, etc...) or there is a visible button
> (i.e. not diplay: none nor visibility: hidden).
>
> Firefox 5 does implicit submission in the following conditions:
>
>     - One text field
>     - One text field with one visible submit button
>     - One text field with one display:none submit button
>     - Two text fields with one visible submit button
>     - Two text fields with one visibility:hidden submit button
>     - Two text fields with one display:none submit button
>
> It does not do implicit submissio in the following conditions:
>
>     - Two text fields

Not doing that last is actually a requirement for web compat, last I
looked at this.

Furthermore, a requirement for web compat is that in the two-textfield
case the submission happen via triggering a click event on the default
submit element for the form and then allowing that to trigger submission
as it would normally (or not trigger it, if the page prevents its
default action, etc).  I expect this event-firing business is why IE has
any sort of dependency on styles for the submit button, and I would not
be surprised if that's why WebKit has it too.

For the one-text-input case, as I recall IE does NOT click the default
submit, at least as of 2002; Gecko used to have that behavior but we
opted for more consistency.  So the current Gecko behavior is to submit
via clicking the default submit input if there is one, else to submit
only if there is only one text control (where the definition of "text
control" is especially interesting, since it of course includes controls
of unknown types, so as new form control types are added things get
_really_ exciting before browsers implement them).

Submitting forms with no submit on enter in a single text control is
also required for web compat, of course.

There is also the separate issue of _which_ controls enter triggers
submission in (e.g. it works in checkbox or radio in Gecko, iirc, but of
course not in textarea).

For those who want to mess with the spec for this behavior,
https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and
https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and
https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but
probably not sufficient) reading.

Also necessary is a decent test matrix and testing in all 4 relevant
engines, of course.

-Boris

[Boris Zbarsky]

On 9/25/11 11:46 AM, Ryosuke Niwa wrote:
> Given the combined market share of Trident and WebKit, I'm not convinced we
> can safely change our behavior without causing compatibility issues.

As a data point, we (Gecko) have never had a compat issue I know of from
submitting on enter when the default submit is display:none or
visibility:hidden.

-Boris

[Glenn Maynard]

On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa <rniwa@...> 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.

--
Glenn Maynard