f



Techniques to prevent accidental press of the Enter key that submits a FORM

Case:=20
an HTML FORM that has many many elements, only a few are set as required IN=
PUTS while it does not necessarily means all other INPUT elements are optio=
nal.  It simply means that other fields are slightly less important.  Thus,=
 we want users to complete as many fields as they see fit (more than the re=
quired fields).

Potential Issue:
Actually it has happened to me several times already (due to "fat" figure),=
 accidentally hit the "Enter" key and the FORM was submitted.

Ways to Prevent such Problem:
One is to use window keydown event with keyCode of 13 and the other is to c=
reate a required INPUT element toward the FORM submission button, if the En=
ter key is accidentally pressed, the label in front of the the required INP=
UT element can ask the user to the effect, "Have you completed the FORM and=
 are ready to submit the form?". =20

The benefit of the second approach is that some of the frequently used inpu=
t VALUES saved to browser cache can be recalled and the Enter key is to sel=
ect such cached value, so, it saves the user from some typing.  Whereas, if=
 the Enter key is disabled, then, such benefit wouldn't be available to the=
 FORM user/users.

I personally prefer the second method.  What do you think?

Thanks.
0
justaguy
12/14/2016 2:48:41 AM
comp.lang.javascript 38370 articles. 0 followers. javascript4 (1315) is leader. Post Follow

20 Replies
132 Views

Similar Articles

[PageSpeed] 44

justaguy <lichunshen84@gmail.com> wrote on 14 Dec 2016 in
comp.lang.javascript: 

> Case: 
> an HTML FORM that has many many elements, only a few are set as required
> INPUTS while it does not necessarily means all other INPUT elements are
> optional.  It simply means that other fields are slightly less
> important.  Thus, we want users to complete as many fields as they see
> fit (more than the required fields). 
> 
> Potential Issue:
> Actually it has happened to me several times already (due to "fat"
> figure), accidentally hit the "Enter" key and the FORM was submitted. 
> 
> Ways to Prevent such Problem:
> One is to use window keydown event with keyCode of 13 and the other is
> to create a required INPUT element toward the FORM submission button, if
> the Enter key is accidentally pressed, the label in front of the the
> required INPUT element can ask the user to the effect, "Have you
> completed the FORM and are ready to submit the form?".  
> 
> The benefit of the second approach is that some of the frequently used
> input VALUES saved to browser cache can be recalled and the Enter key is
> to select such cached value, so, it saves the user from some typing. 
> Whereas, if the Enter key is disabled, then, such benefit wouldn't be
> available to the FORM user/users. 
> 
> I personally prefer the second method.  What do you think?

Should I discuss your preference?

I like to to do this, 
keeping all <input>s free from listeners:

<form 
onsubmit='if (!dosubmit) return false;'>

<input name='x1' value='1'><br>
<input name='x2' value='2'><br>
<input name='x3' value='3'><br>
<input name='x4' value='4'><br>

<button type='button'
onclick='dosubmit="y";this.form.submit();'>
submit</button>

</form>

Remember that, 
it you have specified a different form-target,
keeping the original page intact,
you will have to clear the dosubmit value:

<form target='_blank'
onsubmit='if (!dosubmit) return false;dosubmit="";'>


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
0
Evertjan
12/14/2016 9:14:27 AM
justaguy <lichunshen84@gmail.com> writes:
>Actually it has happened to me several times already (due to
>"fat" figure), accidentally hit the "Enter" key and the FORM
>was submitted.

  This is something the browser manufacturers should have
  solved once and for all forms.

  You could also submit the form on �Enter�, but make sure there
  is a �back� button on the next page. This unifies the best
  of both worlds: No annoying additional confirmation is necessary,
  yet it is possible to go back and continue editing the form
  in the case of an accidental key press.

0
ram
12/14/2016 11:14:47 AM
Stefan Ram wrote:

> justaguy <lichunshen84@gmail.com> writes:
>>Actually it has happened to me several times already (due to
>>"fat" figure), accidentally hit the "Enter" key and the FORM
>>was submitted.
> 
>   This is something the browser manufacturers should have
>   solved once and for all forms.

While I agree for a good user experience that the prevention of user errors 
is important, this is no trivial issue.  What do you suggest they should 
have done?
 
>   You could also submit the form on »Enter«,

JFTR: The form is only submitted on pressing the Enter/Return key if there 
is an *enabled* *submit* button and the element that has the focus is an 
“input” element with a text type (“text”, “email” etc.)

>   but make sure there is a »back« button on the next page. This unifies
>   the best of both worlds: No annoying additional confirmation is
>   necessary, yet it is possible to go back and continue editing the form
>   in the case of an accidental key press.

The Back button/feature is in the browser’s chrome/shortcuts already.  In 
any case, the Back feature will not undo the submission, and submitting the 
same form twice could result in a duplicate or an error.  So I do not see 
your point.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
0
Thomas
12/14/2016 12:04:55 PM
On Wednesday, December 14, 2016 at 4:14:30 AM UTC-5, Evertjan. wrote:
> justaguy <> wrote on 14 Dec 2016 in
> comp.lang.javascript: 
> 
> > Case: 
> > an HTML FORM that has many many elements, only a few are set as required
> > INPUTS while it does not necessarily means all other INPUT elements are
> > optional.  It simply means that other fields are slightly less
> > important.  Thus, we want users to complete as many fields as they see
> > fit (more than the required fields). 
> > 
> > Potential Issue:
> > Actually it has happened to me several times already (due to "fat"
> > figure), accidentally hit the "Enter" key and the FORM was submitted. 
> > 
> > Ways to Prevent such Problem:
> > One is to use window keydown event with keyCode of 13 and the other is
> > to create a required INPUT element toward the FORM submission button, if
> > the Enter key is accidentally pressed, the label in front of the the
> > required INPUT element can ask the user to the effect, "Have you
> > completed the FORM and are ready to submit the form?".  
> > 
> > The benefit of the second approach is that some of the frequently used
> > input VALUES saved to browser cache can be recalled and the Enter key is
> > to select such cached value, so, it saves the user from some typing. 
> > Whereas, if the Enter key is disabled, then, such benefit wouldn't be
> > available to the FORM user/users. 
> > 
> > I personally prefer the second method.  What do you think?
> 
> Should I discuss your preference?
> 
> I like to to do this, 
> keeping all <input>s free from listeners:
> 
> <form 
> onsubmit='if (!dosubmit) return false;'>
> 
> <input name='x1' value='1'><br>
> <input name='x2' value='2'><br>
> <input name='x3' value='3'><br>
> <input name='x4' value='4'><br>
> 
> <button type='button'
> onclick='dosubmit="y";this.form.submit();'>
> submit</button>
> 
> </form>
> 
> Remember that, 
> it you have specified a different form-target,
> keeping the original page intact,
> you will have to clear the dosubmit value:
> 
> <form target='_blank'
> onsubmit='if (!dosubmit) return false;dosubmit="";'>
> 

Interesting technique, thanks.


0
justaguy
12/14/2016 1:42:55 PM
On Wednesday, December 14, 2016 at 7:05:01 AM UTC-5, Thomas 'PointedEars' L=
ahn wrote:
> Stefan Ram wrote:
>=20
> > justaguy <> writes:
> >>Actually it has happened to me several times already (due to
> >>"fat" figure), accidentally hit the "Enter" key and the FORM
> >>was submitted.
> >=20
> >   This is something the browser manufacturers should have
> >   solved once and for all forms.
>=20
> While I agree for a good user experience that the prevention of user erro=
rs=20
> is important, this is no trivial issue.  What do you suggest they should=
=20
> have done?
> =20
> >   You could also submit the form on =C2=BBEnter=C2=AB,
>=20
> JFTR: The form is only submitted on pressing the Enter/Return key if ther=
e=20
> is an *enabled* *submit* button and the element that has the focus is an=
=20
> =E2=80=9Cinput=E2=80=9D element with a text type (=E2=80=9Ctext=E2=80=9D,=
 =E2=80=9Cemail=E2=80=9D etc.)
>=20
> >   but make sure there is a =C2=BBback=C2=AB button on the next page. Th=
is unifies
> >   the best of both worlds: No annoying additional confirmation is
> >   necessary, yet it is possible to go back and continue editing the for=
m
> >   in the case of an accidental key press.
>=20
> The Back button/feature is in the browser=E2=80=99s chrome/shortcuts alre=
ady.  In=20
> any case, the Back feature will not undo the submission, and submitting t=
he=20
> same form twice could result in a duplicate or an error.  So I do not see=
=20
> your point.
>=20


"the Back feature will not undo the submission, and submitting the=20
same form twice could result in a duplicate or an error. ",
totally agree.

In addition, if the form has many dynamically inserted elements, all these =
elements would be gone upon browser's [Back] click.
0
justaguy
12/14/2016 1:45:48 PM
On 12/14/2016 7:04 AM, Thomas 'PointedEars' Lahn wrote:

> JFTR: The form is only submitted on pressing the Enter/Return key if
> there is an *enabled* *submit* button and the element that has the
> focus is an “input” element with a text type (“text”, “email” etc.)

Multiple submit buttons?

<!DOCTYPE html>
<html>
<head>
<style>
body {
  color:black;
  background-color:white;
  margin:1em;
}
label {
  position:relative;
  padding-left:1.5em;
  left:-1.5em;
  z-index:2;
  cursor:pointer;
}
input[id=inpu0] {
  position:relative;
  z-index:1;
}
[hidden] {
  display:none;
}
[id=inpu0]:not(:checked) ~ [type=submit]:not([hidden]) {
  visibility:hidden;
}
</style>
  <title>Multiple Submit Buttons Example</title>
</head>
<body>
  <form id=f0 action="/form.html" method=get>
    <div>
      <input type=text name=n>
    </div>
    <div>
      <input type=checkbox id=inpu0 required>
      <label for=inpu0>check to enable submit</label>
      <input disabled hidden type=submit>
      <input type=submit value=Submit>
    </div>
  </form>
</body>
</html>
0
KnightStalker
12/14/2016 2:33:27 PM
On Tue, 13 Dec 2016 18:48:41 -0800 (PST), justaguy
<lichunshen84@gmail.com> wrote:

  <snip>
>I personally prefer the second method.  What do you think?

There is a third method. In the display that replaces the form after
you press Enter there is a button that lets you edit your choices.
This does mean that the form that is then returned must have the
current choices written into it.=20

This method has the additional advantage that the user can go off and
make a cup of tea half way through filling in the form without
worrying about it being disrupted.

  John
0
John
12/14/2016 3:07:44 PM
KnightStalker wrote:
^^^^^^^^^^^^^
Who?

> On 12/14/2016 7:04 AM, Thomas 'PointedEars' Lahn wrote:
>> JFTR: The form is only submitted on pressing the Enter/Return key if
>> there is an *enabled* *submit* button and the element that has the
>> focus is an “input” element with a text type (“text”, “email” etc.)
> 
> Multiple submit buttons?

Your approach works only if you remove the first, disabled, hidden submit 
button.  Otherwise I cannot submit the form using the Return key in the 
input even after I checked the checkbox.

Why did you think you need multiple submit buttons?

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
0
Thomas
12/14/2016 3:19:18 PM
Am 14.12.2016 um 16:19 schrieb Thomas 'PointedEars' Lahn:
[...]
> Your approach works only if you remove the first, disabled, hidden submit
> button.  Otherwise I cannot submit the form using the Return key in the
> input even after I checked the checkbox.
>
> Why did you think you need multiple submit buttons?
>

To prove your

| if there is an *enabled* *submit* button
               --
wrong, perhaps?

0
Jake
12/14/2016 3:42:46 PM
On 12/14/2016 10:19 AM, Thomas 'PointedEars' Lahn wrote:
> KnightStalker wrote:
> ^^^^^^^^^^^^^
> Who?

Just add a space before the Capital S. Now if you don't like my name,
just ignore it.

>> On 12/14/2016 7:04 AM, Thomas 'PointedEars' Lahn wrote:
>>> JFTR: The form is only submitted on pressing the Enter/Return key if
>>> there is an *enabled* *submit* button and the element that has the
>>> focus is an “input” element with a text type (“text”, “email” etc.)

>> Multiple submit buttons?

> Your approach works only if you remove the first, disabled, hidden submit 
> button.  Otherwise I cannot submit the form using the Return key in the 
> input even after I checked the checkbox.

No need to remove the disable button, that is what prevents an
accidental submission by pressing the Enter/Return key.

Depending on the ua tested in (firefox for example), tab to the submit
button and press (Enter/Return || space) key. Current versions of Google
Chrome and Microsoft Edge, no tabbing required.

Always a good ideal to test on more then on ua yes?

> Why did you think you need multiple submit buttons?

My needs have nothing to do with this.

0
KnightStalker
12/14/2016 4:27:10 PM
KnightStalker wrote:

> On 12/14/2016 10:19 AM, Thomas 'PointedEars' Lahn wrote:
>> KnightStalker wrote:
>> ^^^^^^^^^^^^^
>> Who?
> 
> Just add a space before the Capital S. Now if you don't like my name,
> just ignore it.

This is a Usenet newsgroup, not a chat room.  Pseudonyms are not "cool" 
here, but ridiculous.  I could ignore *you* for this impoliteness, and 
recommend to others to ignore you, but you do not want that to happen.
So here is your last chance to avoid it.
 
>>> On 12/14/2016 7:04 AM, Thomas 'PointedEars' Lahn wrote:
>>>> JFTR: The form is only submitted on pressing the Enter/Return key if
>>>> there is an *enabled* *submit* button and the element that has the
>>>> focus is an “input” element with a text type (“text”, “email” etc.)
>>> Multiple submit buttons?
>> Your approach works only if you remove the first, disabled, hidden submit
>> button.  Otherwise I cannot submit the form using the Return key in the
>> input even after I checked the checkbox.
> 
> No need to remove the disable button, that is what prevents an
> accidental submission by pressing the Enter/Return key.

As a user, after I have checked the checkbox, I want to be able to submit it 
using any means.  Otherwise this form would look broken to me.

> Depending on the ua tested in (firefox for example), tab to the submit
> button and press (Enter/Return || space) key. Current versions of Google
> Chrome and Microsoft Edge, no tabbing required.

If the user had been aware that they could use the Tab key, they would not 
have, before you prevented it, accidentally submitted the form using the 
Return key, would they?
 
> Always a good ideal to test on more then on ua yes?

Yes.
 
>> Why did you think you need multiple submit buttons?
> 
> My needs have nothing to do with this.

Don’t be obtuse.  Oh, wait.

Score adjusted.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
0
Thomas
12/14/2016 5:00:36 PM
Jake Jarvis wrote:

> Am 14.12.2016 um 16:19 schrieb Thomas 'PointedEars' Lahn:
> [...]
>> Your approach works only if you remove the first, disabled, hidden submit
>> button.  Otherwise I cannot submit the form using the Return key in the
>> input even after I checked the checkbox.
>>
>> Why did you think you need multiple submit buttons?
> 
> To prove your
> 
> | if there is an *enabled* *submit* button
>                --
> wrong, perhaps?

You have not tried, perhaps?

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
0
Thomas
12/14/2016 5:00:59 PM
John Harris wrote:

> On Tue, 13 Dec 2016 18:48:41 -0800 (PST), justaguy
> <lichunshen84@gmail.com> wrote:
> 
>   <snip>
>>I personally prefer the second method.  What do you think?
> 
> There is a third method. In the display that replaces the form after
> you press Enter there is a button that lets you edit your choices.

In general, a good idea as, properly done, it can reduce roundtrips.

> This does mean that the form that is then returned must have the
> current choices written into it.

What is preventing the user from making the same mistake on that form?
 
> This method has the additional advantage that the user can go off and
> make a cup of tea half way through filling in the form without
> worrying about it being disrupted.

Not really.  There should be a server-side session, and that session should 
have a timeout, for security.  UX-wise there is not much difference in that 
regard, unless you are thinking about cats jumping on keyboards but 
carefully avoiding the big Enter key that triggers the “Edit My Choices” 
button while the person is making that cup of tea.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
0
Thomas
12/14/2016 10:31:46 PM
On Wednesday, December 14, 2016 at 10:07:39 AM UTC-5, John Harris wrote:
> On Tue, 13 Dec 2016 18:48:41 -0800 (PST), justaguy
> <> wrote:
> 
>   <snip>
> >I personally prefer the second method.  What do you think?
> 
> There is a third method. In the display that replaces the form after
> you press Enter there is a button that lets you edit your choices.
> This does mean that the form that is then returned must have the
> current choices written into it. 
> 
> This method has the additional advantage that the user can go off and
> make a cup of tea half way through filling in the form without
> worrying about it being disrupted.
> 
>   John

Thanks for your input, John. "replace the form..."?  The form has tons of user inputted data already, it's a data input heavy form.

I was thinking of automatic data saving as a user inputs data for one field and move to another... intend to seriously think about this enhancement for next version (tons of work for this to happen, it impacts current work flow as well).


0
justaguy
12/15/2016 10:15:23 PM
On Wednesday, December 14, 2016 at 9:33:32 AM UTC-5, KnightStalker wrote:
> On 12/14/2016 7:04 AM, Thomas 'PointedEars' Lahn wrote:
>=20
> > JFTR: The form is only submitted on pressing the Enter/Return key if
> > there is an *enabled* *submit* button and the element that has the
> > focus is an =E2=80=9Cinput=E2=80=9D element with a text type (=E2=80=9C=
text=E2=80=9D, =E2=80=9Cemail=E2=80=9D etc.)
>=20
> Multiple submit buttons?
>=20
> <!DOCTYPE html>
> <html>
> <head>
> <style>
> body {
>   color:black;
>   background-color:white;
>   margin:1em;
> }
> label {
>   position:relative;
>   padding-left:1.5em;
>   left:-1.5em;
>   z-index:2;
>   cursor:pointer;
> }
> input[id=3Dinpu0] {
>   position:relative;
>   z-index:1;
> }
> [hidden] {
>   display:none;
> }
> [id=3Dinpu0]:not(:checked) ~ [type=3Dsubmit]:not([hidden]) {
>   visibility:hidden;
> }
> </style>
>   <title>Multiple Submit Buttons Example</title>
> </head>
> <body>
>   <form id=3Df0 action=3D"/form.html" method=3Dget>
>     <div>
>       <input type=3Dtext name=3Dn>
>     </div>
>     <div>
>       <input type=3Dcheckbox id=3Dinpu0 required>
>       <label for=3Dinpu0>check to enable submit</label>
>       <input disabled hidden type=3Dsubmit>
>       <input type=3Dsubmit value=3DSubmit>
>     </div>
>   </form>
> </body>
> </html>

While I welcome inputs including yours, the method of "GET" is definitely a=
 NO NO for a FORM that would engage a user with substantial amount of data =
input.

With the GET method, maximum URL length is 2048 characters.
0
justaguy
12/15/2016 10:21:32 PM
On 12/14/2016 12:00 PM, Thomas 'PointedEars' Lahn wrote:
> KnightStalker wrote:

>> On 12/14/2016 10:19 AM, Thomas 'PointedEars' Lahn wrote:
>>> KnightStalker wrote:
>>> ^^^^^^^^^^^^^
>>> Who?

>> Just add a space before the Capital S. Now if you don't like my name,
>> just ignore it.

> This is a Usenet newsgroup, not a chat room. Pseudonyms are not
> "cool" here, but ridiculous. I could ignore *you* for this
> impoliteness, and recommend to others to ignore you, but you do not
> want that to happen. So here is your last chance to avoid it.

Feel free to ignore whom ever you wish and recommend to whom ever you wish.

Would you like me to pause for a moment of silence while scores are
adjusted and recommendations made¿

>>>> On 12/14/2016 7:04 AM, Thomas 'PointedEars' Lahn wrote:

>>>>> JFTR: The form is only submitted on pressing the Enter/Return
>>>>> key if there is an *enabled* *submit* button and the element
>>>>> that has the focus is an “input” element with a text type
>>>>> (“text”, “email” etc.)

>>>> Multiple submit buttons?

>>> Your approach works only if you remove the first, disabled, 
>>> hidden submit button. Otherwise I cannot submit the form using
>>> the Return key in the input even after I checked the checkbox.

>> No need to remove the disable button, that is what prevents an 
>> accidental submission by pressing the Enter/Return key.

> As a user, after I have checked the checkbox, I want to be able to 
> submit it using any means. Otherwise this form would look broken to
> me.

Excellent example of an old old argument and back when all uas wanted to
work like IE. What a ua should do and what it does is not always the
same thing.

>> Depending on the ua tested in (firefox for example), tab to the
>> submit button and press (Enter/Return || space) key. Current
>> versions of Google Chrome and Microsoft Edge, no tabbing required.

> If the user had been aware that they could use the Tab key, they 
> would not have, before you prevented it, accidentally submitted the
> form using the Return key, would they?

Nothing was done to prevent the use of any keys.

[snip]

>>> Why did you think you need multiple submit buttons?

>> My needs have nothing to do with this.

> Don’t be obtuse.  Oh, wait.

> Score adjusted.

The ideal of multiple submit buttons have been around for a very long
time, absolutely nothing new about it.

[url] http://www.alanflavell.org.uk/www/formquestion.html [/url]

html5 example from w3c:
[url] https://www.w3.org/TR/html5/forms.html#concept-fs-novalidate [/url]
0
KnightStalker
12/16/2016 4:03:09 PM
KnightStalker wrote:

> On 12/14/2016 12:00 PM, Thomas 'PointedEars' Lahn wrote:
>> KnightStalker wrote:
>>> On 12/14/2016 10:19 AM, Thomas 'PointedEars' Lahn wrote:
>>>> KnightStalker wrote:
>>>> ^^^^^^^^^^^^^
>>>> Who?
>>> Just add a space before the Capital S. Now if you don't like my name,
>>> just ignore it.
>> This is a Usenet newsgroup, not a chat room. Pseudonyms are not
>> "cool" here, but ridiculous. I could ignore *you* for this
>> impoliteness, and recommend to others to ignore you, but you do not
>> want that to happen. So here is your last chance to avoid it.
> 
> Feel free to ignore whom ever you wish and recommend to whom ever you
> wish.

*plonk*
 
>>> Depending on the ua tested in (firefox for example), tab to the
>>> submit button and press (Enter/Return || space) key. Current
>>> versions of Google Chrome and Microsoft Edge, no tabbing required.
>> If the user had been aware that they could use the Tab key, they
>> would not have, before you prevented it, accidentally submitted the
>> form using the Return key, would they?
> 
> Nothing was done to prevent the use of any keys.

Nonsense.  The very point of this thread is to not make the Enter/Return key 
work by default.  Your very code does that with a disabled, hidden submit 
button.  Probably it is not your own code either, but just cargo cult 
programming.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
0
Thomas
12/16/2016 4:54:00 PM
On 12/15/2016 5:21 PM, justaguy wrote:
> On Wednesday, December 14, 2016 at 9:33:32 AM UTC-5, KnightStalker wrote:
>> On 12/14/2016 7:04 AM, Thomas 'PointedEars' Lahn wrote:

>>> JFTR: The form is only submitted on pressing the Enter/Return key if
>>> there is an *enabled* *submit* button and the element that has the
>>> focus is an “input” element with a text type (“text”, “email” etc.)

>> Multiple submit buttons?

[snip]

>>   <form id=f0 action="/form.html" method=get>
>>     <div>
>>       <input type=text name=n>
>>     </div>
>>     <div>
>>       <input type=checkbox id=inpu0 required>
>>       <label for=inpu0>check to enable submit</label>
>>       <input disabled hidden type=submit>
>>       <input type=submit value=Submit>
>>     </div>
>>   </form>

[snip]

> While I welcome inputs including yours, the method of "GET" is 
> definitely a NO NO for a FORM that would engage a user with
> substantial amount of data input.

> With the GET method, maximum URL length is 2048 characters.

[url] https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.2 [/url]

  ¦  If the processing of a form is idempotent (i.e. it has no lasting
  ¦  observable effect on the state of the world), then the form method
  ¦  should be `GET'. Many database searches have no visible
  ¦  side-effects and make ideal applications of query forms.

[url] https://www.w3.org/TR/html401/interact/forms.html#h-17.13.1 [/url]

  ¦  The "get" method should be used when the form is idempotent (i.e.,
  ¦  causes no side-effects). Many database searches have no visible
  ¦  side-effects and make ideal applications for the "get" method.

In the example posted, the form is idempotent.

0
KnightStalker
12/16/2016 5:24:48 PM
In comp.lang.javascript message <enter-20161214120502@ram.dialup.fu-
berlin.de>, Wed, 14 Dec 2016 11:14:47, Stefan Ram <ram@zedat.fu-
berlin.de> posted:

>justaguy <lichunshen84@gmail.com> writes:
>>Actually it has happened to me several times already (due to
>>"fat" figure), accidentally hit the "Enter" key and the FORM
>>was submitted.
>
>  This is something the browser manufacturers should have
>  solved once and for all forms.
>
>  You could also submit the form on ›Enter‹, but make sure there
>  is a ›back‹ button on the next page. This unifies the best
>  of both worlds: No annoying additional confirmation is necessary,
>  yet it is possible to go back and continue editing the form
>  in the case of an accidental key press.

One must make it very clear that the button must not just repeat the
function of the browser "back" button, but instead must call on the
server-side program to revert to its state before submission of the
previous page and to restore that page, filled in as was submitted.

Any important action must of course be confirmed explicitly; a CAPTCHA
or other evidence might be needed.

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.
 Merlyn Web Site <                       > - FAQish topics, acronyms, & links.


0
Dr
12/17/2016 9:02:22 PM
Dr J R Stockton <reply1600@merlyn.demon.co.uk.invalid> writes:
>In comp.lang.javascript message <enter-20161214120502@ram.dialup.fu-
>berlin.de>, Wed, 14 Dec 2016 11:14:47, Stefan Ram <ram@zedat.fu-
>berlin.de> posted:
>>You could also submit the form on �Enter�, but make sure there
>>is a �back� button on the next page. This unifies the best
>>of both worlds: No annoying additional confirmation is necessary,
>>yet it is possible to go back and continue editing the form
>>in the case of an accidental key press.
>One must make it very clear that the button must not just repeat the
>function of the browser "back" button, but instead must call on the
>server-side program to revert to its state before submission of the
>previous page and to restore that page, filled in as was submitted.

  Yes, I was thinking fullstack, not frontend-only, when I
  wrote this.

  I was thinking first about what I as a user would prefer,
  and only then I was thinking about how to realize this.

0
ram
12/18/2016 11:30:06 AM
Reply: