How to tell which button a user pressed?

[Thomas 'PointedEars' Lahn]

That is an assumption. It could very well be XHTML strict for all you
know.

I have written it to be XHTML 1.0 Transitional, stupid.

Going with your assumption of XHTML transitional, there is still one
error. Can't spot it? Error: There is no attribute "onClick".

There is no "onClick" in my suggestion, stupid.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Eric Bednarz wrote:
Are you sure you want to use XHTML?
Probably not; that small sample contains XHTML errors.

Please don’t feel shy about being specific.

Don't be scared to run the code through the w3c html validator and find
them for yourself.

You don't know what you are talking about. It's a fragment of Valid
XHTML 1.0 Transitional. ^^^^^^^^^^^^^^^^^^^^^^
[...]

Form controls can't be children of a form. They have to be contained
in something else, a fieldset preferably, but a div will do.

Nonsense. Learn to read.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
Neil wrote: [...]
When I look at the posted values, I do not have a value for the
button.
How can I tell which of these buttons the user pressed?
By RTFM and not shooting yourself in the foot:
Link?

Sense?

The OP does not know how to do what he wants done and that responding
with "RTFM" is going to come off as churlish and vague.

Make sense?

And assuming that level of knowledge and intelligence, your posting makes a
whole lot more sense to them. NOT.

Why don't you FOAD?


PointedEars

 

[Thomas 'PointedEars' Lahn]

[Thomas 'PointedEars' Lahn wrote:]

By RTFM and not shooting yourself in the foot:
<form action="..." method="post">
<textarea name="myText" cols="30" rows="3"></textarea>
<input type="submit" name="button" value="Value1" />
<input type="submit" name="button" value="Value2" />
</form>

The problem is that I have text inputs on the form
as well and the customer does not want the return key
to submit the form.

That's a really bad idea. You should tell your customer that this would
create an accessibility problem, with the potential of resulting in a
lawsuit (IANAL), and loss of profit. Most importantly, it would probably
not be compliant with Section 508 of the U.S. Rehabilitation Act (which
could only be a violation if the customer would be or would be selling the
application to a Federal agency, but they might want to uphold high
standards nevertheless).

If I use input type="submit", the form always gets posted with a return
keypress.

No, if you kept your canceling `onsubmit' listener in place, that would not
happen. (Don't do that.)

But instead you can use a keyboard event listener to detect the Return
keypress when the input control has focus, and cancel the event then.

However, users without a pointing device and with script support will not be
able to submit the form other than through tab-focusing either submit button
and pressing Return or Space. Users with a keyboard and without script
support will always be able to submit the form using the Return key with
either text input or submit button having the focus.

Please leave one attribution line for each quotation level.


PointedEars

 

[rf]

Why don't you FOAD?

This, from one of the most hated people around?

 

[rf]

Does not onsubmit="return false" prevent return keypress from submitting
the form?


Keyboard-only users will usually use tab to navigate to the submit button
and then press the space key.

When was the last time you typed a search into google and did not press
enter to make it happen?

 

[Sean Kinsey]

This, from one of the most hated people around?

Hence my "And yes I accidentally hit submit before removing the
signature so don't even think about it." earlier

 

[Bwig Zomberi]

When was the last time you typed a search into google and did not press
enter to make it happen?

I use Enter key when it is available. I use Space key when Enter does
not work. I prefer keyboard shortcuts. I use them a lot. I am just
saying that not all options are closed for me.

The OP could use a function for unsubmit that validates the form and
return a boolean. If true, the form gets submitted. If user presses
Enter without valid form details, the function could show an alert and
return false - the form will not be submitted. That way regular form
behaviour would be restored. Any button and submit controls will also be
submitted.

I am still wondering why button and submit controls are not "Successful
controls" as per:
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.2
when the form is submitted by script

 

[Bwig Zomberi]

This, from one of the most hated people around?

"Most hated?" - That would make his head swell with pride.

A nitpicking PITN mostly.

 

[Scott Sauyet]

I have written it to be XHTML 1.0 Transitional, stupid.

Thomas, you do realize that Garrett was almost certainly NOT referring
to your sample but to the OP's code when he responded to your

|> Are you sure you want to use XHTML?

with

| Probably not; that small sample contains XHTML errors.

don't you? Why should your suggested replacement code have anything
to do with his response?

Perhaps at other times Garrett has earned the insult, but not this
time. I think here it's your confusion at issue.

-- Scott

 

[Thomas 'PointedEars' Lahn]

Thomas, you do realize that Garrett was almost certainly NOT referring
to your sample but to the OP's code when he responded to your

|> Are you sure you want to use XHTML?

with

| Probably not; that small sample contains XHTML errors.

don't you? Why should your suggested replacement code have anything
to do with his response?

Perhaps at other times Garrett has earned the insult, but not this
time. I think here it's your confusion at issue.

I think I am not privileged to confusion:

,-<|
| That is an assumption. It could very well be XHTML strict for all you
| know.

How can it be "XHTML strict" when it would not even qualify as XHTML 1.0
Transitional? ISTM Garrett needs to make up his mind about his assumptions,
or stop making them.


PointedEars

 

[Scott Sauyet]

I think I am not privileged to confusion:

,-<|
| That is an assumption. It could very well be XHTML strict for all you
| know.

How can it be "XHTML strict" when it would not even qualify as XHTML 1.0
Transitional?  ISTM Garrett needs to make up his mind about his assumptions,
or stop making them.

I think it was your assumption that the OP was using an XHTML doctype
that started the confusion and then your misunderstanding of Garrett's
objection that extended it. You were the only one talking about your
proposed alternative code; everyone else, as I understand it, was
talking about the OP's code.

Can you justify your assumption that the OP was trying to use XHTML?
The fragment supplied would not be valid in either HTML 4.01 or XHTML
1.0 documents, but if the form controls were wrapped in a block
element, then it would be a valid fragment of an HTML 4.01 document
but not of a an XHTML one.

-- Scott

 

[Thomas 'PointedEars' Lahn]

I think it was your assumption that the OP was using an XHTML doctype
that started the confusion and then your misunderstanding of Garrett's
objection that extended it.

On which parts the misunderstandings were, remains to be seen.

You were the only one talking about your proposed alternative code;
everyone else, as I understand it, was talking about the OP's code.

Check again.

Can you justify your assumption that the OP was trying to use XHTML?
Yes.

The fragment supplied would not be valid in either HTML 4.01 or XHTML
1.0 documents

Wrong, see below.

but if the form controls were wrapped in a block element, then it would be
a valid fragment of an HTML 4.01 document but not of a an XHTML one.

True. The problem here is that the original code --

<form onsubmit="return false;" action="[action]" method="post">
<textarea name="myText" cols="30" rows="3"></textarea>
<input type="button" name="button" value="Value2"
onClick="this.form.submit();"/>
<input type="button" name="button" value="Value2"
onClick="this.form.submit();"/>
</form>

-- does not make a lot of sense to begin with, so all of us are left with
assumptions what it is supposed to be. One assumption, from which, if
accepted, could be deduced anything, which would not result in a fruitful
discussion, should therefore be excluded from the start: That the OP just
made an accidental typo, or used completely different code. We must
therefore also exclude that "[action]" was anything else than a marked
omission.

Given those premises that leaves the following valid alternative
assumptions:

A) The `onClick' indicates that this is supposed to be HTML. In that case,
it can be Valid HTML 4.01 Transitional, although the output might not
look as expected (if there was a user agent that parsed it strictly,
there would be `>' displayed). It could be made HTML 4.01 Transitional.

B) The `/>' indicates that this is supposed to be XHTML. Then it could be
Valid XHTML 1.0 Transitional were it not for "onClick" instead of
"onclick". It could be made XHTML 1.0 Strict with more changes.

Facing these alternatives, I have applied that scientific principle known as
Occam's Razor, which says in essence that the simplest explanation is
usually the correct one. The Levenshtein distance of the original fragment
to a Valid HTML 4.01 Transitional fragment is 0, to a Valid HTML 4.01 Strict
fragment --

<form onsubmit="return false;" action="[action]" method="post">
<p><textarea name="myText" cols="30" rows="3"></textarea>
<input type="button" name="button" value="Value2"
onClick="this.form.submit();"/>
<input type="button" name="button" value="Value2"
onClick="this.form.submit();"/>
</form>

-- it is greater than or equal to 3, to a Valid XHTML 1.0 Transitional
fragment --

<form onsubmit="return false;" action="[action]" method="post">
<textarea name="myText" cols="30" rows="3"></textarea>
<input type="button" name="button" value="Value2"
onclick="this.form.submit();"/>
<input type="button" name="button" value="Value2"
onclick="this.form.submit();"/>
</form>

-- it is 2, and to a Valid XHTML 1.0 Strict fragment --

<form onsubmit="return false;" action="[action]" method="post">
<p><textarea name="myText" cols="30" rows="3"></textarea>
<input type="button" name="button" value="Value2"
onclick="this.form.submit();"/>
<input type="button" name="button" value="Value2"
onclick="this.form.submit();"/></p>
</form>

-- it is greater than or equal to 9. Considering interoperability in
addition to validity, HTML 4.01 Transitional would score at least 2, while
HTML 4.01 Strict would score at least 9. (The *lowest* score wins here.)

That leaves HTML 4.01 Transitional (0 or 2) and XHTML 1.0 Transitional (2)
as the most likely candidates. Assuming that a newcomer writing such code
would have at least heard about XHTML, given the number of occurrences in
the past where newcomers posted (often invalid) markup with SHORTTAG
syntax that turned out to be supposed to be XHTML, and that the OP used
`onsubmit' where it could have been, for consistency, `onSubmit' in HTML,
I decided that it would be best if I posted my suggestion as an XHTML 1.0
Transitional fragment.

In any case, Garrett's assumption that this might be XHTML 1.0 Strict is,
given these numbers, less likely than all the alternatives except
interoperable Valid HTML 4.01 Strict. And his criticism of my XHTML 1.0
Transitional suggestion is inconsistent with his assumption (in the very
same posting!) that the OP did not want to use XHTML at all.

BTW, Garrett's assumption that Eric changed the code was unjustified, too.
Eric merely quoted my suggestion as quoted by Garrett before, but he removed
the relevant attribution lines.

So much for confusion. EOD?


PointedEars

 

[Thomas 'PointedEars' Lahn]

[...]
Given those premises that leaves the following valid alternative
assumptions:

A) The `onClick' indicates that this is supposed to be HTML. In that
case, it can be Valid HTML 4.01 Transitional, although the output
might not look as expected (if there was a user agent that parsed
it strictly, there would be `>' displayed). It could be made HTML
4.01 Transitional.

^^^^^^^^^^^^
_Strict_


PointedEars

 

[Lasse Reichstein Nielsen]

Gordon wrote:

Nonsense. Learn to read.

From the XHTML 1.0 Transitional DTD [1]:

<!ELEMENT form %form.content;>
....
<!ENTITY % form.content "(%block; | %misc*">
....
<!ENTITY % misc "noscript | %misc.inline;">
....
<!ENTITY % misc.inline "ins | del | script">
....
<!ENTITY % heading "h1|h2|h3|h4|h5|h6">
<!ENTITY % lists "ul | ol | dl">
<!ENTITY % blocktext "pre | hr | blockquote | address">

<!ENTITY % block
"p | %heading; | div | %lists; | %blocktext; | fieldset | table">

I.e., form controls (elements "input", "select", "textarea", "button"
and "object") cannot be children of a "form" element in valid XHTML
1.0 Transitional. They may be descendants (e.g., inside a "p" or
"fieldset" element"), but not children.

/L 'Being arrogant and wrong isn't worse than being arrogant and right,
just more embarrasing'

[1] http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_block

 

[Lasse Reichstein Nielsen]

Gordon wrote:

Form controls can't be children of a form. They have to be contained
in something else, a fieldset preferably, but a div will do.

Nonsense. Learn to read.

From the XHTML 1.0 Transitional DTD [1]:

No, look again.

Damn, you are right. There is more than one DTD in that page, and I
was using the strict one.
For Transitional, %inline is a valid form element content.

Guess that'll apply to me then.
/L

 

[Garrett Smith]

[...]


Given those premises that leaves the following valid alternative
assumptions:

You spen so much time trying to justify your nutty assumptions and
theory for inducing probability for what the OP's doctype was. Silly!

Why didn't you just ask him if you wanted to know?

A) The `onClick' indicates that this is supposed to be HTML. In that case,
it can be Valid HTML 4.01 Transitional, although the output might not
look as expected (if there was a user agent that parsed it strictly,
there would be `>' displayed). It could be made HTML 4.01 Transitional.

B) The `/>' indicates that this is supposed to be XHTML. Then it could be
Valid XHTML 1.0 Transitional were it not for "onClick" instead of
"onclick". It could be made XHTML 1.0 Strict with more changes.

Facing these alternatives, I have applied that scientific principle known as
Occam's Razor,

Oh brother. You really believe the OP was thinking along those lines?

You have no idea what was the doctype was.

Taking the OPs code, please create ONE valid document out of that
fragment as markup, using either:
XHTML transitional XHTML Strict, HTML Transitional, or HTML Strict.

You can't do it, so just please leave Occam's Razor or whatever
pointlessness goes on between your ears is out of it.

[snip nonsense]

 

[Scott Sauyet]

On which parts the misunderstandings were, remains to be seen.

Only by you, I'm afraid.

Check again.

I just did. Although your code fragment was carried through in many
quotations, I don't see anything that looks to be discussing that
code. If you have a few minutes, could you try something? Re-read
the thread assuming that everyone but you is discussing the OP's code,
and see if Garrett looks less stupid.

Yes.

Okay. I should warn you that I don't scare easily. Boring me to
death is always possible, though.

Wrong, see below.

You're right. It wouldn't be valid in either Strict mode, though.

but if the form controls were wrapped in a block element, then it would be
a valid fragment of an HTML 4.01 document but not of a an XHTML one.

True.  The problem here is that the original code --

  <form onsubmit="return false;" action="[action]" method="post">
  <textarea name="myText" cols="30" rows="3"></textarea>
  <input type="button" name="button" value="Value2"
  onClick="this.form.submit();"/>
  <input type="button" name="button" value="Value2"
  onClick="this.form.submit();"/>
  </form>

-- does not make a lot of sense to begin with, so all of us are left with
assumptions what it is supposed to be.  One assumption, from which, if
accepted, could be deduced anything, which would not result in a fruitful
discussion, should therefore be excluded from the start: That the OP just
made an accidental typo, or used completely different code.  

I'm more than willing to believe that the OP retyped the code from
memory rather than cut-and-pasted it intact. I'm further willing to
believe that in doing so, he accidentally made some mistakes that
changed the validity of the fragment. I would also certainly
entertain the notion that it never validated properly in the first
place. So I don't quite buy your assumption that this is the original
code modulo only the following:

We must therefore also exclude that "[action]" was anything else than a
marked omission.
Agreed.


Given those premises that leaves the following valid alternative
assumptions:

A) The `onClick' indicates that this is supposed to be HTML.  In that case,
   it can be Valid HTML 4.01 Transitional, although the output might not
   look as expected (if there was a user agent that parsed it strictly,
   there would be `>' displayed).  It could be made HTML 4.01 Transitional.

B) The `/>' indicates that this is supposed to be XHTML.  Then it couldbe
   Valid XHTML 1.0 Transitional were it not for "onClick" instead of
   "onclick".  It could be made XHTML 1.0 Strict with more changes.

I'm not quite willing to accept your premises, but these alternative
assumptions nonetheless seem proper.

Facing these alternatives, I have applied that scientific principle knownas
Occam's Razor, which says in essence that the simplest explanation is
usually the correct one.  The Levenshtein distance of the original fragment
to a Valid HTML 4.01 Transitional fragment is 0, to a Valid HTML 4.01 Strict
fragment --

Occam's Razor makes more sense based on conceptual differences than on
the Levenshtein distances. The latter are really only apply if one
accepts your assumption that this code is changed only minimally
between the code under test and the fragment posted here. I don't buy
that.

[ ... deleted Levenshtein calculations ... ]

Considering interoperability in
addition to validity, HTML 4.01 Transitional would score at least 2, while
HTML 4.01 Strict would score at least 9.  (The *lowest* score wins here..)

From what hat did you pull those numbers?

That leaves HTML 4.01 Transitional (0 or 2) and XHTML 1.0 Transitional (2)
as the most likely candidates.  Assuming that a newcomer writing such code
would have at least heard about XHTML, given the number of occurrences in
the past where newcomers posted (often invalid) markup with SHORTTAG
syntax that turned out to be supposed to be XHTML, and that the OP used
`onsubmit' where it could have been, for consistency, `onSubmit' in HTML,
I decided that it would be best if I posted my suggestion as an XHTML 1.0
Transitional fragment.

So your logic is based on the idea that since there would be more
characters to change in adding a block-level wrapper than there would
be to in changing the capitalization of two attributes, the latter is
significantly more likely to have occurred accidentally? That's a
pretty slim thread.

And somehow I don't believe that you actually explicitly made those
calculations before I challenged you.

In any case, Garrett's assumption that this might be XHTML 1.0 Strict is,
given these numbers, less likely than all the alternatives except  
interoperable Valid HTML 4.01 Strict.  And his criticism of my XHTML 1.0  
Transitional suggestion is inconsistent with his assumption (in the very
same posting!) that the OP did not want to use XHTML at all.

Are you simply playing dumb here or is it not an act? Garrett did not
make the assumption about the document type. You made an assumption,
and Garrett challenged it. When you misunderstood and assumed he was
discussing your snippet, things got confused.

BTW, Garrett's assumption that Eric changed the code was unjustified, too..  
Eric merely quoted my suggestion as quoted by Garrett before, but he removed
the relevant attribution lines.

Yes, Garrett's quoting habits leave a lot to be desired and have
contributed to this mess, starting with his first post in the thread
where he left intact your (irrelevant) code snippet when he responded
to the question about XHTML.

So much for confusion.  EOD?

Of course not!

 

[Thomas 'PointedEars' Lahn]

[...]
Considering interoperability in addition to validity, HTML 4.01
Transitional would score at least 2, while HTML 4.01 Strict would score
at least 9. (The *lowest* score wins here.)

From what hat did you pull those numbers?

I have only seen later that the end tag of the P element is not necessary
for Valid HTML 4.01 Strict. Hence the correction near the example code, but
not here. For interoperable HTML you would need to remove the 2 slashes
from the original code which increases the Levenshtein distance computed
before by 2. So it is 0+2=2 and 3+2=5, respectively, or 0+2=2 and 7+2=9 if
you want the end tag, too. Which is still greater than or equal to 2 (XHTML
1.0 Transitional), though.

Of course not!

Troll^WSuit yourself, then. I gave you what you asked for.


PointedEars

 

[Scott Sauyet]

Troll^WSuit yourself, then.  I gave you what you asked for.

Have you yet recognized that Garrett was not being obtuse and that it
was your confusion at issue?