Problem applying HTML 4.01 DOM in scripting

M

Michael Winter

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]
[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]

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
 
R

Richard Lionheart

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
 
R

RobG

VK said:
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? :)
#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){


[...]
 
R

RobG

Richard said:
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.

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:

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

Thomas 'PointedEars' Lahn

VK said:
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
 
V

VK

Thomas said:
VK said:
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?
 
T

Thomas 'PointedEars' Lahn

VK said:
Thomas said:
VK said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,022
Latest member
MaybelleMa

Latest Threads

Top