Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #31846 > unrolled thread

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

Back to article view | Back to comp.lang.javascript

Contents

  Techniques to prevent accidental press of the Enter key that submits a FORM justaguy <lichunshen84@gmail.com> - 2016-12-13 18:48 -0800
    Re: Techniques to prevent accidental press of the Enter key that submits a FORM "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-12-14 10:14 +0100
      Re: Techniques to prevent accidental press of the Enter key that submits a FORM justaguy <lichunshen84@gmail.com> - 2016-12-14 05:42 -0800
    Re: Techniques to prevent accidental press of the Enter key that submits a FORM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-12-14 13:04 +0100
      Re: Techniques to prevent accidental press of the Enter key that submits a FORM justaguy <lichunshen84@gmail.com> - 2016-12-14 05:45 -0800
      Re: Techniques to prevent accidental press of the Enter key that submits a FORM KnightStalker <7oo7le7roupie@gmail.com> - 2016-12-14 09:33 -0500
        Re: Techniques to prevent accidental press of the Enter key that submits a FORM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-12-14 16:19 +0100
          Re: Techniques to prevent accidental press of the Enter key that submits a FORM Jake Jarvis <pig_in_shoes@yahoo.com> - 2016-12-14 16:42 +0100
            Re: Techniques to prevent accidental press of the Enter key that submits a FORM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-12-14 18:00 +0100
          Re: Techniques to prevent accidental press of the Enter key that submits a FORM KnightStalker <7oo7le7roupie@gmail.com> - 2016-12-14 11:27 -0500
            Re: Techniques to prevent accidental press of the Enter key that submits a FORM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-12-14 18:00 +0100
              Re: Techniques to prevent accidental press of the Enter key that submits a FORM KnightStalker <7oo7le7roupie@gmail.com> - 2016-12-16 11:03 -0500
                Re: Techniques to prevent accidental press of the Enter key that submits a FORM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-12-16 17:54 +0100
                  Re: Techniques to prevent accidental press of the Enter key that submits a FORM KnightStalker <7oo7le7roupie@gmail.com> - 2017-01-06 15:08 -0500
        Re: Techniques to prevent accidental press of the Enter key that submits a FORM justaguy <lichunshen84@gmail.com> - 2016-12-15 14:21 -0800
          Re: Techniques to prevent accidental press of the Enter key that submits a FORM KnightStalker <7oo7le7roupie@gmail.com> - 2016-12-16 12:24 -0500
    Re: Techniques to prevent accidental press of the Enter key that submits a FORM John Harris <niam@jghnorth.org.uk.invalid> - 2016-12-14 15:07 +0000
      Re: Techniques to prevent accidental press of the Enter key that submits a FORM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-12-14 23:31 +0100
      Re: Techniques to prevent accidental press of the Enter key that submits a FORM justaguy <lichunshen84@gmail.com> - 2016-12-15 14:15 -0800
    Re: Techniques to prevent accidental press of the Enter key that submits a FORM Dr J R Stockton <reply1600@merlyn.demon.co.uk.invalid> - 2016-12-17 21:02 +0000

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

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?

Thanks.

[toc] | [next] | [standalone]

#31847

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)

[toc] | [prev] | [next] | [standalone]

#31851

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.

[toc] | [prev] | [next] | [standalone]

#31850

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.

[toc] | [prev] | [next] | [standalone]

#31852

On Wednesday, December 14, 2016 at 7:05:01 AM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Stefan Ram wrote:
> 
> > 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.
> > 
> >   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.
> 


"the Back feature will not undo the submission, and submitting the 
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.

[toc] | [prev] | [next] | [standalone]

#31853

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>

[toc] | [prev] | [next] | [standalone]

#31855

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.

[toc] | [prev] | [next] | [standalone]

#31856

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?

[toc] | [prev] | [next] | [standalone]

#31861

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.

[toc] | [prev] | [next] | [standalone]

#31857

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.

[toc] | [prev] | [next] | [standalone]

#31860

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.

[toc] | [prev] | [next] | [standalone]

#31883

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]

[toc] | [prev] | [next] | [standalone]

#31885

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.

[toc] | [prev] | [next] | [standalone]

#32131

On 12/16/2016 11:54 AM, Thomas 'PointedEars' Lahn wrote:

> KnightStalker wrote:

>> On 12/14/2016 12:00 PM, Thomas 'PointedEars' Lahn wrote:

[snip]

>>> 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.

This thread is about preventing implicit submission, even though the OP
did not explicitly use that phrase.

Is it my markup or not¿ Cargo cult programming¿

The disabled, hidden submit button does exactly what was intended.

I.e. The form is not implicitly submitted.

[url] https://www.w3.org/TR/html5/forms.html#implicit-submission [/url]

4.10.22.2 Implicit submission

  ¦  A form element's default button is the first submit button
  ¦  in tree order whose form owner is that form element.

  ¦  If the user agent supports letting the user submit a form
  ¦  implicitly (for example, on some platforms hitting the
  ¦  "enter" key while a text field is focused implicitly submits
  ¦  the form), then doing so for a form whose default button has
  ¦  a defined activation behavior must cause the user agent to
  ¦  run synthetic click activation steps on that default button.

  ¦  Note:  Consequently, if the default button is disabled,
  ¦         the form is not submitted when such an implicit
  ¦         submission mechanism is used. (A button has no
  ¦         activation behavior when disabled.)

  ¦ …

  ¦  If the form has no submit button, then the implicit
  ¦  submission mechanism must do nothing if the form has more
  ¦  than one field that blocks implicit submission, and must
  ¦  submit the form element from the form element itself
  ¦  otherwise.

  ¦ …

[toc] | [prev] | [next] | [standalone]

#31878

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?
> 
> <!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>

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.

[toc] | [prev] | [next] | [standalone]

#31887

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.

[toc] | [prev] | [next] | [standalone]

#31854

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. 

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

[toc] | [prev] | [next] | [standalone]

#31871

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.

[toc] | [prev] | [next] | [standalone]

#31877

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).

[toc] | [prev] | [next] | [standalone]

#31891

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web