Differences between perhaps-similar constructs?

**Thomas 'PointedEars' Lahn** · Jun 27 '08, 07:12 PM

Re: Differences between perhaps-similar constructs?

gentsquash@gmai l.com wrote:

Inside of <script></script>, inside of <body></body>, what
are the differences between
>
document.body.c lassName="mysty le";
and
document.body.s etAttribute("cl ass", "mystyle");
>
? (...assuming that a CSS "mystyle" has been defined.)

The first one is supposed to work, due to buggy implementations the second
one is not always supposed to work. The first one is therefore recommended.

=============== =============== =============== =============== ====
What are the differences between
>
word = new String("td");
and
word = createTextNode( "td");
?

The first one creates a new String object with the value "td" and returns a
reference to it that is then stored in `word'. Usually such is overkill as
ECMAScript implementations define the primitive string type:

word = "td";

The second one, as it is, likely causes a ReferenceError exception as no
object in the scope chain has such a method; if you meant

word = document.create TextNode("td");

instead, if supported it creates a new object implementing the TextNode
interface, with nodeValue == "td", and returns a reference to it that is
then stored in `word'. `word' referring to such an object can be used to
add a text node to the DOM tree; `word' referring to a String object or
`word' storing a string value cannot.

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

**Kris Kowal** · Jun 27 '08, 07:12 PM

Re: Differences between perhaps-similar constructs?

The question you actually ought to ask is, what are the differences
among:

"td"
new String("td")
String("td")
document.create TextNode("td")

I defer to PointedEars's answers for your questions about className
and createTextNode. However, the other forms are more nuanced. When
you
use the "new" keyword before a type like "String", or "Number", it
creates
a boxed object which is distinct from a string or number literal.
Here
are some invariants:

typeof "" == "string"

typeof String("") == "string"

typeof new String("") == "object"

These are all equivalent:
new String(x).toStr ing()
String(x)
x.toString()
"" + x

And these are all equivalent:
new Number(n).value Of()
Number(n)
n.valueOf()
+n

I personally avoid using "new".

VK · Jun 27 '08, 07:12 PM

Re: Differences between perhaps-similar constructs?

On May 23, 8:33 pm, gentsqu...@gmai l.com wrote:

Inside of <script></script>, inside of <body></body>, what
are the differences between
>
document.body.c lassName="mysty le";
and
document.body.s etAttribute("cl ass", "mystyle");
>
? (...assuming that a CSS "mystyle" has been defined.)

First of all, it is not important _where_ the script is located: it is
only important _when_ it is called. In the particular
document.body.s omething=anythi ng can be only executed after DOM Tree
being ready thus after window's load event fired. Before that point
document.body is null so such expression will result in runtime error.
This way the proper question is:

After document being successfully loaded and window's load event
fired, is there any difference between i) scripting DOM interfaces and
ii) direct element node manipulation, other words are
document.body.c lassName="mysty le";
and
document.body.s etAttribute("cl ass", "mystyle");
equal by their functionality or not?

The answer is "yes and no". Yes, the resulting effect is often _but
not always_ the same. No, these are two technically completely
different processes where the first (scripting DOM interfaces) has to
be always used in Javascript and the second (direct element node
manipulation) should be used only in a narrow set of particular
circumstances.

The scripting DOM interfaces does exactly what the name implies and
what programmer wants: it gets/sets scriptable element properties to
affects its runtime look and/or behavior. Say
document.body.c lassName="mysty le";
means "apply to body style rules defined in mystyle class"
It also reflects the changes in the DOM Tree, so the body's node gets
extra attribute node "class" with value "mystyle". You can check that
by querying document.body.h asAttribute("cl ass") afterwards - except
for IE where hasAttribute is not functional until IE8 beta. But this
additional DOM Tree update happens only for properties defined in the
element's scriptable DOM interface. Say
document.body.f oobar = "foobar";
adds extra property to the DOM interface which you can use later - but
it is not reflected in the DOM Tree,
document.body.h asAttribute("fo obar") == false

From the other side getAttribute, setAttribute and hasAttribute
methods are intended to manipulate the element's node in the DOM Tree.
In the particular
document.body.s etAttribute("cl ass", "mystyle");
means "create attribute node "class" and set the text node value to
"mystyle". In many circumstances it still leads to DOM interface
requests afterwards so say document.body gets the style rules of
mystyle class applied. This behavior is of the same kind as say
window.location in IE allowed to be used both as a field and a method.
Other words sometimes it is easier to break the model rather than
trying to fight with legions of developers stubbornly making the same
mistake over and over again.

So to sum up the answer: always use the DOM scripting which is correct
- or use the setAttribute sidewalk which is silly but mostly
functional.

In either case there are two situations where only one of ways is
suitable.

1) For each DOM interface there is a predefined set of properties and
methods it has by default. The attribute nodes with names not listed
in the set are not reflected in the DOM interface, at least not in all
browsers. Say having an element like
<input type="text"
name="email" id="email"
filltype="manda tory">
in Firefox will create an element node with attribute nodes "type",
"name", "id", "filltype". At the same time DOM interface will reflect
only three of them ("type", "name", "id") so
document.forms['myform'].email.filltype
will be undefined because "filltype" is not in the default list. To
get the values of custom attribute one has then to use getAttribute
to query the DOM Tree:
document.forms['myform'].email.getAttri bute('filltype' )
will return "mandatory"

2) Intrinsic event handlers have to be set _only_ over the DOM
interface:
document.forms['myform'].onclick = myFunction;

// WRONG:
document.forms['myform'].
email.setAttrib ute('onclick', 'alert(this.nam e)');
Now you know the above means "create "onclick" attribute node and set
its text node value to "alert(this.nam e)". By knowing it you will not
expect anymore that setting some text node value would have anything
to do with element event handlers. And this is a correct conclusion
because say IE does exactly what it means and nothing more: it creates
the mode with text value "alert(this.nam e)" but no event handler for
the input element. Event handlers are for DOM interface, not for DOM
Tree.

=============== =============== =============== =============== ====
What are the differences between
>
word = new String("td");
and
word = document.create TextNode("td");
?

The first creates Javascript String object with valueOf "td"
The second creates DOM Tree text node with value "td".

The actual difference depends on how and where either is being used.

Differences between perhaps-similar constructs?

Differences between perhaps-similar constructs?

Comment

Comment

Comment