Hi All,
I've taken the advice of a few people and managed to cobble together an
HTML 4.01 Strict-compliant document (according to the W3C Validation
Service), but the way I try to pass a TextArea object to a script
function doesn't work.
What's the least amount of change I can make to this to remain
compliant but also correct for execution?
TIA,
Richard
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>An "HTML 4.01 Strict" compliant document</title>
<meta http-equiv="Content-Style-Type" content="text/css" >
<meta http-equiv="content-type"
content="text/html;charset=ISO-8859-1" >
<style type="text/javascript">
#red {color:red}
.blue {color:blue}
</style>
<script type="text/javascript">
function GenLines(o, n)
{
var aL = []; // Array of lines, sans newlines, which will
populate MyTextArea
// when concatenated with newline separators
// if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
{
for (var i=1; i<=n; i++)
{
aL.push("Line " + i);
}
o.value = aL.join("\n");
}
}
</script>
</head>
<body>
<div>
<p>
... Your HTML content here ...</p>
<p id="red">
DOCTYPEs are "seatbelts" for HTML authors</p>
<p><b class="blue">Item 1</b> <i>Item 2</i></p>
<input id="Button1" type="button" value="Click for 12 lines"
onclick="GenLines(MyTextArea, 12)" />
<br />
<br />
<input id="MyTextArea" style="width: 420px; height: 122px"
type="text" /></div>
</body>
</html> 29  1651 
Richard Lionheart wrote: , but the way I try to pass a TextArea object to a script
function doesn't work.
<input id="Button1" type="button" value="Click for 12 lines"
onclick="GenLines(MyTextArea, 12)" />
MyTextArea is an underfined variable. You probably want something like:
onclick="GenLines(this.form.elements['MyTextArea'], 12);"
<br />
Don't use XHTML style self closing tags in HTML. Their meaning is different.
<input id="MyTextArea" style="width: 420px; height: 122px"
type="text" /></div>
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Richard Lionheart wrote: Hi All,
I've taken the advice of a few people and managed to cobble together an
HTML 4.01 Strict-compliant document (according to the W3C Validation
Service), but the way I try to pass a TextArea object to a script
function doesn't work.
What's the least amount of change I can make to this to remain
compliant but also correct for execution?
TIA,
Richard
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>An "HTML 4.01 Strict" compliant document</title>
<meta http-equiv="Content-Style-Type" content="text/css" >
<meta http-equiv="content-type"
content="text/html;charset=ISO-8859-1" >
<style type="text/javascript">
#red {color:red}
.blue {color:blue}
</style>
<script type="text/javascript">
function GenLines(o, n)
{
var aL = []; // Array of lines, sans newlines, which will
populate MyTextArea
// when concatenated with newline separators
// if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
{
for (var i=1; i<=n; i++)
{
aL.push("Line " + i);
}
o.value = aL.join("\n");
}
}
</script>
</head>
<body>
<div>
<p>
... Your HTML content here ...</p>
<p id="red">
DOCTYPEs are "seatbelts" for HTML authors</p>
<p><b class="blue">Item 1</b> <i>Item 2</i></p>
<input id="Button1" type="button" value="Click for 12 lines"
onclick="GenLines(MyTextArea, 12)" />
<br />
<br />
<input id="MyTextArea" style="width: 420px; height: 122px"
type="text" /></div>
</body>
</html>
Was it a check for local public? ;-)
This page cannot possibly be a valid HTML of any kind just because it
uses XHTML tag format />
Also input=text accepts *single line text*. For multiline text you use
<textarea>. Also... any way, there is no "minimum change" here - it has
to be completely rewritten. Study the valid variant, do not hesitate to
ask if some changes are not clear:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML Strict 4.01//EN"
"http://www.w3.org/TR/html401/strict.dtd">
<html>
<head>
<title>An "HTML 4.01 Strict" compliant document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
#red {color:red}
.blue {color:blue}
</style>
<script type="text/javascript">
function GenLines(o, n) {
var aL = [];
for (var i=0; i<=n; i++) {
aL.push("Line " + i);
}
o.value = aL.join("\n");
}
</script>
</head>
<body>
<p>
... Your HTML content here ...</p>
<p id="red">
DOCTYPEs are "seatbelts" for HTML authors</p>
<p><b class="blue">Item 1</b> <i>Item 2</i></p>
<form action="">
<fieldset>
<legend>Hello W3C world!</legend>
<input id="Button1" type="button" value="Click for 12 lines"
onClick="GenLines(this.form.elements['MyTextArea'],12)">
<br>
<br>
<textarea name="MyTextArea" cols="20" rows="12"></textarea>
</fieldset>
</form>
</body>
</html>
VK wrote: This page cannot possibly be a valid HTML of any kind just because it
uses XHTML tag format />
Actually, it can.
<foo /> means the same as <foo>> and thus <foo>> in HTML. So anywhere you
are allowed character data, you can use XHTML style self-closing tags and
be valid. (So <img> and <br>, along with <hr> in some circumstances).
Of course, while it is valid, it doesn't mean what you are trying to say, so
it should be avoided. (You just can't expect the Markup Validator to pick
up on that error).
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Hi David,
Thanks for taking the trouble to respond to my question. You probably want something like:
onclick="GenLines(this.form.elements['MyTextArea'], 12);"
I sure do. But I didn't want my code embedded in <form> tags because
the W3C validator wanted an "action" attribute for <form>.
To get this working, I:
-- switched to "form"
-- removed <br />
-- re-established a conditional around my "for" loop that had been
recommended
This was partially successful. I got "Line 1" in MyTextArea, but not
12 "Line x" entries stacked in TextArea that I had gotten before I
switched to this DOM approach.
I added a debug line before the loop, and that yielded "n = 12"
(confirming that the count was being passed successfully to the
function) instead of "Line 1".
If you can give me another push forward, I might be able to climb this
mountain :-)
Again, thanks in advance.
Richard
******** Revised code ************
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>An "HTML 4.01 Strict" compliant document</title>
<meta http-equiv="Content-Style-Type" content="text/css" >
<meta http-equiv="content-type"
content="text/html;charset=ISO-8859-1" >
<style type="text/javascript">
#red {color:red}
.blue {color:blue}
</style>
<script type="text/javascript">
function GenLines(o, n)
{
var aL = []; // Array of lines, sans newlines, which will
populate MyTextArea
// when concatenated with newline separators
// aL.push("n = " + n); // DEBUG
if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
{
for (var i=1; i<=n; i++)
{
aL.push("Line " + i);
}
o.value = aL.join("\n");
}
}
</script>
</head>
<body>
<form action="FormOutput.txt">
<p>
... Your HTML content here ...</p>
<p id="red">
DOCTYPEs are "seatbelts" for HTML authors</p>
<p>
<b class="blue">Item 1</b> <i>Item 2</i></p>
<p><input id="Button1" type="button" value="Click for 12 lines"
onclick="GenLines(this.form.elements['MyTextArea'], 12)"
/></p>
<p>
<input id="MyTextArea" style="width: 420px; height: 122px"
type="text" /></p>
</form>
</body>
</html>
Richard Lionheart wrote: If you can give me another push forward, I might be able to climb this
mountain :-)
Please see the working and validated example I already posted.
<form action=""> is the regular way to pacify validator (method is
"GET" by default). The most important HTML error made (skipping on
script) is that input=text accept *single line text*. To display
multiline text you have to use <textarea>
Hey VK and David,
You folks are great. I see where all the mistakes are now. I'm going
to clean it up now and post back for just a couple of follow-up
questions if W3Schools et al don't seem to provide relevant guidance.
Thanks to you both.
Regards,
Richard
David Dorward wrote: VK wrote:
This page cannot possibly be a valid HTML of any kind just because it
uses XHTML tag format />
Actually, it can.
Actually it cannot ;-)
By reading <http://www.w3.org/TR/html401/strict.dtd> (which no one
seems to read but everyone links :-) we see no "/" as valid entity
within <...>
The allowed entities are spelled rather explicetly: tag name itself,
tag attribute name, tag attribute value, event handler name, etc...
"/" character is neither of all of this, so must be treated equally
with say "wrap" attribute or any other unrecognized entity.
The only reason Validator doesn't get upset on it is because it was
intentionally patched to stimulate XHTML usage (in any shall perform
form).
Hey VK, your suggestions work GREAT. Many thanks. which no one seems to read but everyone links :-)
Hey, nobody sits down and reads the entire dictionary either :-)
But your preceding comment explains why M/S VWD keep closing "<br" with
" />" when I key in a simple ">".
Both of you folks have resuscitated my understanding that ensuring
every tag had closure was an XML requirement, not an HTML issue.
And it was great to find out that including <fieldset> obviated the
need for those <p> tags I had to apply as a kludge to avoid complaints
from the W3C Validator.
I originally had a <textarea> specification but lost it unknowingly
when I accepted someone else's idea of "objectifying" my original code.
QUESTION: What do you think of the protection this other person
recommended around the function. Is it helpful. If I use it,
shouldn't have "else alert" code accompanying it?
Again, thanks to you both for helping me escape my frustration and
enlightening me at the same time.
Best wishes,
Richard
Woops. Here's the clean code for my personal "model comploiant code":
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>An "HTML 4.01 Strict" compliant document</title>
<meta http-equiv="Content-Style-Type" content="text/css" >
<meta http-equiv="content-type"
content="text/html;charset=ISO-8859-1" >
<style type="text/javascript">
#red {color:red}
.blue {color:blue}
</style>
<script type="text/javascript">
function GenLines(o, n)
{
var aL = []; // Array of lines, sans newlines, which will
populate MyTextArea
// when concatenated with newline separators
if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
{
for (var i=1; i<=n; i++)
{
aL.push("Line " + i);
}
o.value = aL.join("\n");
}
}
</script>
</head>
<body>
<p>
... Your HTML content here ...</p>
<p id="red">
DOCTYPEs are "seatbelts" for HTML authors</p>
<p>
<b class="blue">Item 1</b> <i>Item 2</i></p>
<form action="">
<fieldset>
<legend>Hello W3C world!</legend>
<input id="Button1" type="button" value="Click for 12 lines"
onclick="GenLines(this.form.elements['MyTextArea'], 12)">
<br><br>
<textarea name="MyTextArea" cols="20" rows="12"></textarea>
</fieldset>
</form>
</body>
</html>
Richard Lionheart wrote: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Wrong DTD link: must be <http://www.w3.org/TR/html401/strict.dtd>
because you are reffering HTML 4.01, not HTML 4.0
<html>
<head>
<title>An "HTML 4.01 Strict" compliant document</title>
<meta http-equiv="Content-Style-Type" content="text/css" >
This meta tag is useless as it was not implemented by any browser, it
is just mention in one of W3C recommendation. It is also harmless as it
may you think that now you can skip on type declaration in the the
<style> tag itself.
<meta http-equiv="content-type"
content="text/html;charset=ISO-8859-1" >
HTTP-EQUIV metas usually presented in the same sase as they would be
sent from server: "Content-Type", not "content-type".
<style type="text/javascript">
Pardon? :-)
<style type="text/css">
#red {color:red}
.blue {color:blue}
</style>
<script type="text/javascript">
function GenLines(o, n)
{
var aL = []; // Array of lines, sans newlines, which will
populate MyTextArea
// when concatenated with newline separators
if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
This is completely unnecessary and wrong besides that: you are using
assignment operator (=) instead of comparison operator (==). So you
just consecutively assigning the most fantastic values to poor "o". The
last value your assign is undefined (because o['MyTextArea'] property
doesn't exist). Just remove it completely.
So the working (and valid) variant is:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html401/strict.dtd">
<html>
<head>
<title>An "HTML 4.01 Strict" compliant document</title>
<meta http-equiv="Content-Type"
content="text/html;charset=ISO-8859-1">
<style type="text/css">
#red {color:red}
.blue {color:blue}
</style>
<script type="text/javascript">
function GenLines(o, n)
{
var aL = []; // Array of lines, sans newlines,
// which will populate MyTextArea
// when concatenated with newline separators
for (var i=1; i<=n; i++)
{
aL.push("Line " + i);
}
o.value = aL.join("\n");
}
</script>
</head>
<body>
<p>
... Your HTML content here ...</p>
<p id="red">
DOCTYPEs are "seatbelts" for HTML authors</p>
<p>
<b class="blue">Item 1</b> <i>Item 2</i></p>
<form action="">
<fieldset>
<legend>Hello W3C world!</legend>
<input id="Button1" type="button" value="Click for 12 lines"
onClick="GenLines(this.form.elements['MyTextArea'], 12)">
<br><br>
<textarea name="MyTextArea" cols="20" rows="12"></textarea>
</fieldset>
</form>
</body>
</html>
VK wrote: <form action=""> is the regular way to pacify validator
Is it? That's not very nice.
If you aren't planning to submit the data to a server then there shouldn't
be a form at all (rather then a form that submits to the current URL).
For that matter, if you are displaying data, then you shouldn't use a form
control (as those are designed for the user to enter data).
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
VK wrote: By reading <http://www.w3.org/TR/html401/strict.dtd> (which no one
seems to read but everyone links :-) we see no "/" as valid entity
within <...>
It isn't allowed (unquoted) within a tag. It _ends_ a tag. The DTD doesn't
say that ">" ends a tag either. This is specified in the SGML
specification.
http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.7 points out that such
things are valid but badly supported.
"/" character is neither of all of this, so must be treated equally
with say "wrap" attribute or any other unrecognized entity.
The only reason Validator doesn't get upset on it is because it was
intentionally patched to stimulate XHTML usage (in any shall perform
form).
Not true. I haven't looked at the precise details of what the validator does
in XML mode, but for HTML documents it continues to use SGML mode.
The W3C Markup Validator correctly reads:
<p> foo <br /> bar </p>
as:
foo bar
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
David Dorward wrote: VK wrote:
<form action=""> is the regular way to pacify validator
Is it? That's not very nice.
Complain to W3C, not to me. That should be default value for action ==
current page longest time ago. Another thing to do as soon as DTD's
will be finally taking from the freezer.
If you aren't planning to submit the data to a server then there shouldn't
be a form at all (rather then a form that submits to the current URL).
An interesting idea. As soon as we manage to prohibit web applications,
ajaxoids, XML+XSL, data binding and other terrible stuff people dared
to invent since 1999, I may follow this advise. To start with I would
initiate death penalty request for using ajaxoids. ;-)
For that matter, if you are displaying data, then you shouldn't use a form
control (as those are designed for the user to enter data).
Form is the user interface. How to handle the data is up to programmer.
Web application? AJAX? Bush Jr. president, Clinton is gone way ago? ;-)
VK wrote: Richard Lionheart wrote:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Wrong DTD link: must be <http://www.w3.org/TR/html401/strict.dtd>
because you are reffering HTML 4.01, not HTML 4.0
If I visit "http://www.w3.org/TR/html4/strict.dtd" it says:
This is HTML 4.01 Strict DTD
It also says:
Typical usage:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
And if I pay a visit to http://www.w3.org/QA/2002/04/valid-dtd-list.html -
the same version appears there.
So Richard is using the correct form.
<title>An "HTML 4.01 Strict" compliant document</title>
<meta http-equiv="Content-Style-Type" content="text/css" >
This meta tag is useless as it was not implemented by any browser, it
is just mention in one of W3C recommendation.
"Mention" meaning "It is required if you use any intrinsic events" (which
Richard does).
It is also harmless as it may you think that now you can skip on type
declaration in the the <style> tag itself.
I think you mean "harmful" there ... and since the validator will complain
about a missing type attribute such a misapprehension is unlikely. <meta http-equiv="content-type"
content="text/html;charset=ISO-8859-1" >
HTTP-EQUIV metas usually presented in the same sase as they would be
sent from server: "Content-Type", not "content-type".
http://www.w3.org/Protocols/rfc2616/...c4.html#sec4.2
Field names are case-insensitive.
So it really doesn't matter.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
VK wrote: If you aren't planning to submit the data to a server then there
shouldn't be a form at all (rather then a form that submits to the
current URL).
An interesting idea. As soon as we manage to prohibit web applications,
Well they would use a form and SUBMIT DATA TO THE SERVER.
ajaxoids,
Should have a form that will submit data to the server as a fallback if the
JavaScript fails,
XML+XSL,
What does that have to do with using a form but not intending to submit data
to the server?
data binding
What does that have to do with using a form but not intending to submit data
to the server?
For that matter, if you are displaying data, then you shouldn't use a
form control (as those are designed for the user to enter data).
Form is the user interface. How to handle the data is up to programmer.
Eh? Form controls are UI controls to get data from the user. HTML has many
other elements to markup information that is being displayed to the user.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
David Dorward wrote: It isn't allowed (unquoted) within a tag. It _ends_ a tag. The DTD doesn't
say that ">" ends a tag either. This is specified in the SGML
specification.
An interesting idea. So the relevant DTD specs must look something like
"DTD rules applicability sequentially decreases from left to right
withing the tag and it reaches zero applicability at the last position
before >" :-)
It doesn't look right though, because say <br /> leaves Validator
happy, but <br !> leads to "character "!" not allowed in attribute
specification list". I would be happy to find "/" in DTD attribute
specification list, but it is not there.
So it is an intentional patch, and Validator was/is/will (at least
partially) a brain waching tool for pushing desired behavior.
We may continue this in ciwah if you want to (I don't).
VK wrote: It doesn't look right though, because say <br /> leaves Validator
happy, but <br !> leads to "character "!" not allowed in attribute
specification list".
<br !>
< - Start of tag
br - This is a br element
! - not allowed - end of tag
<br />
< - Start of tag
br - this is a br element
/ - end of tag - a greater than character (as text to appear after the line break)
So it is an intentional patch, and Validator was/is/will (at least
partially) a brain waching tool for pushing desired behavior.
No.
We may continue this in ciwah if you want to (I don't).
Fine. Follow-ups set.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Hi VK,
Thanks for your additional contribution to reform my errant ways :-) <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> Wrong DTD link: must be > <http://www.w3.org/TR/html401/strict.dtd>
because you are referring HTML 4.01, not HTML 4.0
Thanks for noticing that. I didn't, and even if I had I would have
said "If it ain't broke ...".
I haven't tried it out yet, but I got this from "HTML 4.01 -
Strict ..." at http://www.w3.org/QA/2002/04/valid-dtd-list.html, so
you might be wrong here, though you've batted 1000 so far!!
<meta http-equiv="Content-Style-Type" content="text/css" >
This meta tag is useless as it was not implemented by any browser, it
is just mention in one of W3C recommendation. It is also HARMLESS as
it may you think that now you can skip on type declaration in the
<style> tag itself.
Hmm, sounds like it might be harmful, not "harmless" :-)
I don't know where I got this and the next Meta tag. But I agree it
is harmless for me ... I won't be tempted to short-change the <style>
tag :-)
<style type="text/javascript">
Pardon? :-)
<style type="text/css">
I'm mystified as to how ="javascript" got in there. Probably a
brain-freeze in my head, but I was about to get to it indirectly as I
investigated how my colors stopped working all of a sudden. Thanks for
solving my problem before
being asked about it :-)
if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
This is completely unnecessary and wrong besides that: you are usingassignment operator (=) instead of comparison operator (==).
Yes, I noticed this. I've done a lot of C and C++ over a couple of
decades, but I didn't feel a need to attack this problem at once.
So the working (and valid) variant is: ...
Thanks. I've made the changes in my current document that you
identified above. I've saved your version as a benchmark for mine to
be referenced a little later.
Again, thanks for weighing in so effectively.
Regards,
Richard
On 18/03/2006 19:49, VK wrote:
[snip] It doesn't look right though, because say <br /> leaves Validator
happy
I'm surprised you haven't read about this before. It's been mentioned
numerous times in various groups.
A slash used in a start tag creates a NET-enabling start tag. NET, or
null end-tag, is a shortened tag form:
<p class="note">...content...</p>
can be written as:
<p class="note"/...content.../
The first slash ends the list of attributes, and the second closes the
element.
For elements with an EMPTY content model, the first slash ends both the
attribute list and the element itself. Therefore, in HTML:
<br />
is actually:
<br>>
This is, of course, mostly academic. Browsers do not implement HTML as
an application of SGML. Nevertheless, constructs such as these should
not appear in HTML markup.
but <br !> leads to "character "!" not allowed in attribute
specification list".
Quite correct, as an exclamation mark in the attribute list doesn't
match any of the productions in SGML.
I would be happy to find "/" in DTD attribute specification list, but
it is not there.
As David implied, this has nothing to do with any DTD. It is a feature
of SGML, enabled in the SGML declaration for HTML.
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail. > if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
This is completely unnecessary and wrong besides that: you are usingassignment operator (=) instead of comparison operator (==).
Actually it is not undefined after all assignments, and it even works
as intended. A totally cool sample of how a completely wrong code can
work by occasion :-)
Initially o contains a reference to textarea element.
if ((o = o.form)
form element has .form property pointing to owner form.
o now contains a reference to the whole form.
&& (o = o.elements)
o now contains a reference to the elements collection in the form
&& (o = o['MyTextArea']))
o again contains a reference to textarea element retrieved from the
elements collection.
No one of these assignments has a result undefuned, so the entire block
gets value of the last assignment (textarea reference).
A valid reference is being evaluated to true within if() statement, so
the inner blocks is executed.
Really cool. :-)
On 18/03/2006 20:55, Richard Lionheart wrote: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Wrong DTD link: must be > <http://www.w3.org/TR/html401/strict.dtd>
because you are referring HTML 4.01, not HTML 4.0
Thanks for noticing that.
He noticed nothing; he's wrong.
Whilst the path, /TR/html401/, does contain the latest version of HTML
4.01, the path, /TR/html4/, contains the latest version of HTML 4. They
are equivalent, and will remain so as there won't be further versions of
HTML 4.
[snip]
<meta http-equiv="Content-Style-Type" content="text/css" >
[snip]
I don't know where I got this and the next Meta tag.
The HTML specification describes the Content-Style-Type and
Content-Script-Type http-equiv attribute values. Whilst technically
useful, they're practically unnecessary as browsers do not generally
implement more than one scripting language, and those that do (IE)
default to JScript, anyway.
[snip]
if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
This is completely unnecessary and wrong besides that: you are
using assignment operator (=) instead of comparison operator (==).
Rubbish. If the variable, o, was a reference to a control within the
form, that code would be perfectly fine.
Whilst one could argue that such a style is unnecessary as the
assignments could be performed separately,
if (o.form) {
o = o.form;
if (o.elements) {
o = o.elements;
if (o.MyTextArea) {
o = o.MyTextArea;
/* ... */
}
}
}
it's very unwieldy.
However, the if statement (and its assignments) is unnecessary as the
variable is a reference to the MyTextArea control.
[snip]
So the working (and valid) variant is: ...
What VK should have also mentioned about your document is that
background colour declarations should be paired with foreground colours,
and margins should be used in preference to line breaks.
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Hi VK,
Great analysis! I thought that code was weird because I wrote a lot of
C and C++ where = is for assignment and == is expected inside
if-statement predicates. But of course, usage like the current case is
not uncommon, especially in C, where brevity is valued highly. From your analysis, I take it the containment in javascript is like
inheritence, so since MyTextArea is contained in the elements
collection, which is in turn contained in the form collection, then a
MyTextArea reference *is a* elements reference *is a* form reference.
Does that sound like a correct analysis to you?
Secondly, do you agree that if we use this sort of guard around the
for-loop, we should have a succeeding 'else' clause, e.g.
else (alert(GenLines called with non-MyTextArea-object");)
Regards,
Richard
VK wrote: Richard Lionheart wrote:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Wrong DTD link: must be <http://www.w3.org/TR/html401/strict.dtd>
because you are reffering HTML 4.01, not HTML 4.0
<html>
<head>
<title>An "HTML 4.01 Strict" compliant document</title>
<meta http-equiv="Content-Style-Type" content="text/css" >
This meta tag is useless as it was not implemented by any browser, it
is just mention in one of W3C recommendation. It is also harmless as it
may you think that now you can skip on type declaration in the the
<style> tag itself.
<meta http-equiv="content-type"
content="text/html;charset=ISO-8859-1" >
HTTP-EQUIV metas usually presented in the same sase as they would be
sent from server: "Content-Type", not "content-type".
<style type="text/javascript">
Pardon? :-)
<style type="text/css">
#red {color:red}
.blue {color:blue}
</style>
<script type="text/javascript">
function GenLines(o, n)
{
var aL = []; // Array of lines, sans newlines, which will
populate MyTextArea
// when concatenated with newline separators
if ((o = o.form) && (o = o.elements) && (o = o['MyTextArea']))
This is completely unnecessary
Unnecessary in this case yes, but not always. In the original post by the
OP in another thread, the name of the element was passed to 'o' with a
reference to another element in the form, therefore it was needed.
But here a reference to the required element is being passed so only a test
for existence of the element referenced by 'o' is required:
if (o){
and wrong besides that: you are using
It was 'right' for the original post: testing along the way to ensure the
required components are found.
assignment operator (=) instead of comparison operator (==). So you
The assignment operator is intended. If at any stage the assignment fails,
the 'undefined' result will be type converted to 'false' and the if block
is not executed. However, in this case the OP is going from the required
element, back to the form and down to the required element again.
So while it is redundant, it isn't 'wrong'.
just consecutively assigning the most fantastic values to poor "o". The
Not 'fantastic' values at all, but the ones intended.
last value your assign is undefined (because o['MyTextArea'] property
doesn't exist). Just remove it completely.
Initially, 'o' is assigned a reference to the element named 'MyTextArea'.
When entering the if statement, it is assigned the value of 'o.form', which
is the form. It is then assigned the value of 'o.elements', which is the
elements collection of the form. It is finally assigned the value of
'o['MyTextArea']', which exists (at least in the posted code).
It is equivalent to:
o = o.form.elements['MyTextArea'];
but since o is a reference to 'MyTextArea' to start with, it's redundant.
I would suggest keeping:
if(o){
[...]
--
Rob
Richard Lionheart wrote: Hi VK,
Great analysis! I thought that code was weird because I wrote a lot of
C and C++ where = is for assignment and == is expected inside
if-statement predicates. But of course, usage like the current case is
not uncommon, especially in C, where brevity is valued highly.
From your analysis, I take it the containment in javascript is like inheritence, so since MyTextArea is contained in the elements
collection, which is in turn contained in the form collection, then a
MyTextArea reference *is a* elements reference *is a* form reference.
Does that sound like a correct analysis to you?
The elements are 'contained' only in the sense of the original HTML markup
where the element tags are nested. In the DOM tree, they are children,
like branches on a tree rather than contained like boxes within boxes.
So the element tags nested withing a form's tags in the source HTML are
converted to a tree structure of child nodes in the DOM.
However, the DOM also includes some special interfaces. Certain elements
that are children of a form can also be form controls (input, textarea,
select, etc.) and they belong to the form's elements collection.
Read the DOM HTML spec:
<URL:http://www.w3.org/TR/DOM-Level-2-HTML/>
Especially the interface HTMLFormElement:
<URL:http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357>
And about collections:
<URL:http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506>
Secondly, do you agree that if we use this sort of guard around the
for-loop, we should have a succeeding 'else' clause, e.g.
else (alert(GenLines called with non-MyTextArea-object");)
Maybe. If you want your users to see error messages, then yes. It is
often only useful to give users error messages about things that they can
fix, like invalid data entry or not filling in a form properly.
Otherwise, allow for graceful degradation so that if the loop fails, the
user never notices. The functionality is provided in some other way
without them knowing.
Of course in testing you might toss up errors to help you out, but not in
'production' code that makes in onto the web.
--
Rob
VK wrote: > >> if ((o = o.form) && (o = o.elements) && (o =
> >> o['MyTextArea']))
> This is completely unnecessary and wrong besides that: you are using
> >assignment operator (=) instead of comparison operator (==).
Actually it is not undefined after all assignments, and it even works
as intended. A totally cool sample of how a completely wrong code can
work by occasion :-)
The code (which was suggested to "Richard" by me) is not wrong at all.
There was no intention of doing a comparison of the inner operands in
the first place.
You are merely in a delusional state, as usual.
PointedEars
Thomas 'PointedEars' Lahn wrote: VK wrote:
> >> if ((o = o.form) && (o = o.elements) && (o =
> >> o['MyTextArea']))
> This is completely unnecessary and wrong besides that: you are using
> >assignment operator (=) instead of comparison operator (==).
Actually it is not undefined after all assignments, and it even works
as intended. A totally cool sample of how a completely wrong code can
work by occasion :-)
The code (which was suggested to "Richard" by me) is not wrong at all.
There was no intention of doing a comparison of the inner operands in
the first place.
But in the name the purpose of this?? To check to see if document.forms
and document.forms[n].elements collections are supported? They were
implemented since JavaScript 1.0 / JScript 1.0. The code as it is (with
layout losses of course) will work on Netscape 2.x So what potential
browser are you checking against?
VK wrote: Thomas 'PointedEars' Lahn wrote: VK wrote: >> > >> if ((o = o.form) && (o = o.elements) && (o =
>> > >> o['MyTextArea']))
>> > This is completely unnecessary and wrong besides that: you are using
>> > >assignment operator (=) instead of comparison operator (==).
> Actually it is not undefined after all assignments, and it even works
> as intended. A totally cool sample of how a completely wrong code can
> work by occasion :-)
The code (which was suggested to "Richard" by me) is not wrong at all.
There was no intention of doing a comparison of the inner operands in
the first place.
But in the name the purpose of this?? To check to see if document.forms
and document.forms[n].elements collections are supported? They were
implemented since JavaScript 1.0 / JScript 1.0. The code as it is (with
layout losses of course) will work on Netscape 2.x So what potential
browser are you checking against?
Wrong question. They refer to _host objects_ since JavaScript 1.4.
PointedEars
Thomas 'PointedEars' Lahn wrote: Wrong question. They refer to _host objects_ since JavaScript 1.4.
OK, then the right question:
Against of what browser are you checking the presence of DOM 0 support?
VK wrote: Thomas 'PointedEars' Lahn wrote: Wrong question. They refer to _host objects_ since JavaScript 1.4.
OK, then the right question:
Against of what browser are you checking the presence of DOM 0 support?
Good question.
PointedEars This discussion thread is closed Replies have been disabled for this discussion. Similar topics
12 posts
views
Thread by Burton Figg |
last post: by
|
6 posts
views
Thread by NoCopy na |
last post: by
|
10 posts
views
Thread by Mark McLellan |
last post: by
|
4 posts
views
Thread by Stephen |
last post: by
|
2 posts
views
Thread by Fernando Barsoba |
last post: by
|
6 posts
views
Thread by ged |
last post: by
|
34 posts
views
Thread by Simon Wigzell |
last post: by
|
8 posts
views
Thread by toby989 |
last post: by
| | | | | | | | | | | | | | | | | | | | | |
