By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,993 Members | 1,883 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,993 IT Pros & Developers. It's quick & easy.

Button click honored by FireFox, but not IE, on a 15-line test page

P: n/a
Hi All,

The test page follows. Clicking the button brings up a message box
announcing that the browser had entered the function intended to
populate the text area. Dismissing the message box leads to the
message box being populated with a dozen lines.

At least, that's what happens with Firefox. With IE, clicking the
button does nothing. Any idea why?

Regards,
Richard

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>An "HTML 4.01 Strict" compliant document</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<script>
function GenLines(n)
{
alert("Reached 'GetLines'");
for (var i=1; i<=n; i++)
{
document.MyForm.MyTextArea.value += "Line " + i + "\n";
}
}
</script>
</head>
<body>
<form name="MyForm">
<input id="Button1" type="button" value="Click for 12 lines"
onclick="GenLines(12)" /><br />
<br />
<textarea id="MyTextArea" style="width: 571px; height:
200px"></textarea></form>
</body>
</html>

Mar 15 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a

By default, type="button" submits, so, I'd think IE is submitting to
a null action, just add ;return false, to the event handler, so the
event doesn't get returned.

Danny
Mar 15 '06 #2

P: n/a
Danny said the following on 3/15/2006 12:47 AM:
By default, type="button" submits,


BULLSHIT.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 15 '06 #3

P: n/a
Danny wrote:
By default, type="button" submits, [...]


Wrong. You are confusing `input[type="button"]', which is not a submit
button by itself (it can become one through scripting), and `button'.
The default value of the `type' attribute of the _`button'_ element is
"submit".

| <!ATTLIST INPUT
| %attrs; -- %coreattrs, %i18n, %events --
| type %InputType; TEXT -- what kind of widget is needed --
| [...]

| <!ATTLIST BUTTON
| %attrs; -- %coreattrs, %i18n, %events --
| name CDATA #IMPLIED
| value CDATA #IMPLIED -- sent to server when submitted --
| type (button|submit|reset) submit -- for use as form button --
| [...]
PointedEars
Mar 15 '06 #4

P: n/a
Richard Lionheart wrote:
^^^^^^^^^^^^^^^^^
Were you not supposed to be dead long ago?
The test page follows. Clicking the button brings up a message box
announcing that the browser had entered the function intended to
populate the text area. Dismissing the message box leads to the
message box being populated with a dozen lines.
No it does not. Probably you meant to write "textarea" for
the second "message box".
At least, that's what happens with Firefox. With IE, clicking the
button does nothing. Any idea why?
See <URL:http://jibbering.com/faq/#FAQ4_43>.

And your markup is not Valid: <URL:http://validator.w3.org/>
Since IE does not support XHTML and you do not need it here,
you should stick to HTML 4.01 Strict. If you ever use XHTML
again, serve it as application/xhtml+xml, not text/html:

<URL:http://hixie.ch/advocacy/xhtml>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>An "HTML 4.01 Strict" compliant document</title>
You must be kidding.
<meta http-equiv="content-type" content="text/html;charset=utf-8" /> ^^^^^
Is this really the encoding you used for creating the resource? If
not, either omit the line (and use the correct HTTP headers instead),
or have this line match the actual HTTP header if that is correct.
The "charset" component of the Content-Type HTTP header always takes
precedence over this line in a conforming client (even in IE).
[...]
document.MyForm.MyTextArea.value += "Line " + i + "\n";


Should be standards compliant:

document.forms['MyForm'].elements['MyTextArea'].value ...

However, you should pass a reference to the form or the control instead:

function genLines(o, n)
{
if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
{
// ... o ...
}
}

<input type="button" value="Click for 12 lines"
onclick="genLines(this, 12)">

The `+=' string concatenation should be replaced by something more
efficient, such as

var a = [];
for (...)
{
a.push(...);
}
... = a.join("\n");
HTH

PointedEars
Mar 15 '06 #5

P: n/a
Zif
Thomas 'PointedEars' Lahn said on 16/03/2006 5:28 AM AEST:
Richard Lionheart wrote:
^^^^^^^^^^^^^^^^^
Were you not supposed to be dead long ago?


That was Richard *the* Lionheart!

--
Zif
Mar 16 '06 #6

P: n/a
>> Dismissing the message box leads to the
message box being populated with a dozen lines. No it does not. Probably you meant to write
"textarea" for the second "message box".


I stand corrected :-)
See <URL:http://jibbering.com/faq/#FAQ4_43>.
Thanks. That's nice to know
<URL:http://validator.w3.org/>
Ditto

Since IE does not support XHTML
That explains much of the stuff that confused me about IE
If you ever use XHTML again, serve it as
application/xhtml+xml, not text/html:
<URL:http://hixie.ch/advocacy/xhtml>
Thanks for that and especially the link presenting
the situation in detail.
<title>An "HTML 4.01 Strict" compliant document</title> You must be kidding.
No, I wasn't kidding. I was expressing my intent,
and that title provoked the kind of advice I hoped
to get so as to achieve that goal!
Is this really the encoding you used for creating the resource?
I doubt it. I was using the Microsoft Visual Web Developer 2005
Express Edition
to compose the HTML, so I suppose the encoding is simply ASCII.
If not, either omit the line (and use the correct HTTP headers instead),
or have this line match the actual HTTP header if that is correct.
The "charset" component of the Content-Type HTTP header always takes
precedence over this line in a conforming client (even in IE).
I'm opting to omission of any encoding specification.
document.MyForm.MyTextArea.value += "Line " + i + "\n";

Should be standards compliant:
document.forms['MyForm'].elements['MyTextArea'].value ...


OK, since standards-compliance is my goal. Question: Both IE and
Firefox handled the more succint form, so was the latter established
originally and been since deprecated in the current standard. I like
the succint approach, of course, especially since it feels like C++ to
me, though I may be wrong in that.
However, you should pass a reference to the form or the control instead:

function genLines(o, n)
{
if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
{
// ... o ...
}
}

<input type="button" value="Click for 12 lines"
onclick="genLines(this, 12)">
OK, but I've got to study this.
The `+=' string concatenation should be replaced by something more
efficient, such as

var a = [];
for (...)
{
a.push(...);
}
... = a.join("\n");
I agree fully. I was just doing a "quick and dirty" just to check out
whether I could populate the "textarea".
HTH


It helped a great deal. I'll hang on this annotated page so that I get
it all implement in my reference implementations.

Thank you very much for taking the time for offering an informed
critique.

Best wishes,
Richard

Mar 16 '06 #7

P: n/a
> That was Richard *the* Lionheart!

Exactly. This way I could claim his glorious image without actually
stealing his title. :-)

Anyway, I don't favor posting a real name or email address on public
newsgroups, etc.. One of these days I'll create a dummy account for
this purpose.

Mar 16 '06 #8

P: n/a
Richard Lionheart wrote:

[(Re)added attribution lines, see the bottom of this posting for details]
Thomas 'PointedEars' Lahn wrote:
"Richard Lionheart" wrote:
[...]
Is this really the encoding you used for creating the resource?
I doubt it. I was using the Microsoft Visual Web Developer 2005
Express Edition
to compose the HTML, so I suppose the encoding is simply ASCII.


More like ISO-8859-xx or Windows-125x. (US-)ASCII is a 7-bit encoding
rarely used for text files nowadays.
If not, either omit the line (and use the correct HTTP headers instead),
or have this line match the actual HTTP header if that is correct.
The "charset" component of the Content-Type HTTP header always takes
precedence over this line in a conforming client (even in IE).


I'm opting to omission of any encoding specification.


That would be utter nonsense, though. Read RFC1945 and RFC2616.
document.MyForm.MyTextArea.value += "Line " + i + "\n";

Should be standards compliant:
document.forms['MyForm'].elements['MyTextArea'].value ...


OK, since standards-compliance is my goal. Question: Both IE and
Firefox handled the more succint form, so was the latter established
originally and been since deprecated in the current standard.

^
If that is a question: Yes, the shorter form originates from the so-called
DOM Level 0, introduced with JavaScript 1.0 (when [NN] DOM objects were
still part of the core language), and implemented since the 3.0 versions
of Netscape Navigator (NN) and Microsoft Internet Explorer. However, DOM
Level 0 already supported those forms-elements references, too. That is
why the latter is highly recommended: it is both standards compliant _and_
fully backwards compatible (with _named_ forms/controls; there are some
issues with IDs).
However, you should pass a reference to the form or the control instead:

function genLines(o, n)
{
if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
{
// ... o ...
}
}

<input type="button" value="Click for 12 lines"
onclick="genLines(this, 12)">


OK, but I've got to study this.


It is not that complicated. `this' is a reference to the element object
representing the target element of the (click) event (here: the
input[type="button"] element). The combinations of paranthesed assignments
and AND operations allow for shallow references while evaluating each
property value step-by-step at the same time. If any assignment evaluates
to a false-value (such as, not an object reference), the type-converting
test evaluates to `false', the following tests are not performed, and the
corresponding block is not executed.
Thank you very much for taking the time for offering an informed
critique.


You are welcome.

Please provide attribution of quoted material next time:

<URL:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>
<URL:http://www.safalra.com/special/googlegroupsreply/>
Regards,
PointedEars
Mar 16 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.