Changing text between <div>'s

[Ton den Hartog]

Stupid basic question but I find it horribly imposible to find the answer
elsewhere... :-(

I want to have a piece of text in my HTML page and want to be able to change
it in a Javascript function that is called from a button. I think I can use
a

<div id="t"></div>

for this ? Something like

document.t.value="Hello"

should change it into

<div id="t">Hello</div>

I am getting fucking mad at finding these simple things.... Is there a good
intro somewhere ? My thick Oreilly JS book is just too busy with the
complicated stuff somehow :-((

Ton

 

[Ton den Hartog]

Ok, already solved it. Remembered I asked this once before....

document.getElementById('t').firstChild.nodeValue="Hello";

Unbelievable how complex.... Will look for the model of this....

Thanks,

Ton

 

[Ton den Hartog]

Why is this so complex ??? Why does DOM not have an easy model for this ????

Ton

 

[Jim Ley]

Why is this so complex ??? Why does DOM not have an
easy model for this ????

DOM is not designed to be simple it's designed to be consistent across
programming languages, I have no idea why that was a design aim, but
it is, this means what can be done simply in typeless scripting
language doesn't get into the language if it would make the java or
LISP binding more complicated.

It's often best to use the proprietary methods, as these generally are
optimised for scripting, and only fallback to DOM if they don't work.

Jim.

 

[Ton den Hartog]

It's often best to use the proprietary methods

Which is in this case ?

Thanks,

Ton



, as these generally are

 

[Fabian]

Ton den Hartog hu kiteb:

Which is in this case ?

document.t.innerhtml

You'll want to double check the case - its sensitive iirc.

 

[Lasse Reichstein Nielsen]

Ton den Hartog hu kiteb:


document.t.innerhtml

That would fail in all browsers

Even if you write it "innerHTML", it would still fail in IE and probably
also other browsers.

To get the element to change, use
document.getElementById("t")
That is the method that works in the most current browsers.
If you need to support IE 4 (or possibly WebTV), you can
use a fallback to the document.all collection:
---
var elem;
if (document.getElementById) {
elem = document.getElementById("t");
} else if (document.all) { // IE 4 and a few other
elem = document.all["t"];
} // else (e.g., Netscape 4) panic.
---
Just writing "document.t" assumes that the named element is made a
property, with the same name, of the document element. That is not
the case in, e.g., Internet Explorer. (Using just "t.innerHTML"
would break in Mozilla/Netscape for similar reasons - just use
getElementById!)

You can then change the content with the proprietary (but widely
implemented) innerHTML property:

var elem = document.getElementById("t");
elem.innerHTML = "some <em>HTML<\/em> content";

If you want to check for the existence of the innerHTML property
before using it, you have two choices:
Simple:

var elem = document.getElementById("t");
if (elem.innerHTML) { ... }

That has the disadvantage of creating a very large string if elem has
a lot of content already. That is inefficient.

Smart, but dangerous:
var elem = document.getElementById("t");
if ("innerHTML" in elem) { ... }

That has the disadvantage of not working in older browsers. I am not
sure any of those support "innerHTML", but that kind of ruins the
idea of testing.

The syntax ("name" in obj) was introduced in JScript 1.0 (according to
MSDN, so IE it should work in any version of IE), and JavaScript 1.4
(Netscape 6 and later, not Netscape 4). The very bad thing about it
is, that browsers that don't support it, treats it as a syntax error.
That means that it breaks the entire script block it is in.

You'll want to double check the case - its sensitive iirc.

Yes, Javascript is case sensitive.

/L

 

[DU]

DOM is not designed to be simple it's designed to be consistent across
programming languages, I have no idea why that was a design aim, but
it is, this means what can be done simply in typeless scripting
language doesn't get into the language if it would make the java or
LISP binding more complicated.

It's often best to use the proprietary methods,

I disagree. CharacterData attributes and methods are widely and well
supported in recent browsers. If we are talking about text nodes only
(CharacterData objects), then use of proprietary methods is not
recommendable. If we are talking about element nodes, then this is a
different issue.

Unless someone can prove me wrong, all DOM2 CharacterData attributes and
methods are supported 100% by the following browsers:
Safari 1.x
Konqueror 3.x
MSIE 6 for Windows
Mozilla-based browsers (17 browsers) based on Mozilla 1.x
Opera 7.x

So why use anything else than CharacterData attributes and methods?

DU

as these generally are

 

[DU]

DOM is not designed to be simple it's designed to be consistent across
programming languages, I have no idea why that was a design aim, but
it is, this means what can be done simply in typeless scripting
language doesn't get into the language if it would make the java or
LISP binding more complicated.

It's often best to use the proprietary methods, as these generally are
optimised for scripting, and only fallback to DOM if they don't work.

Jim.

In my own tests, MSIE 6 for windows, Mozilla 1.x, NS 7.1 all render text
node changes 300% faster if you change the text node with W3C DOM
nodeValue than by resorting to innerHTML. This percentage is as high/big
as 2000% on some Opera 7.x versions.
The performance gain will be greater for long text nodes and slow cpu.
The performance gain will be smaller for short text nodes and fast cpu.

Performance comparison between innerHTML attribute and DOM's nodeValue
when modifying the text data of a node of type TEXT_NODE:
http://www10.brinkster.com/doctorunclear/HTMLJavascriptCSS/innerHTMLvsNodeValue.html

DOM level 2 CharacterData Interface tests
http://www10.brinkster.com/doctorunclear/HTMLJavascriptCSS/DOM2CharacterData.html

DU

 

[DU]

Ok, already solved it. Remembered I asked this once before....

document.getElementById('t').firstChild.nodeValue="Hello";

Unbelievable how complex.... Will look for the model of this....

Thanks,

Ton

Your original code was itself part of the problem. When you write

<div id="t"></div>

then there is no firstChild node in such code. No childNodes either.
MSIE 6 for Windows, Mozilla 1.7alpha, Opera 7.50 PR1 all return null
when querying for document.getElementById("t").firstChild. Just by
inserting a single word or blank space in that div would have made a
difference though.

Further reading:
Nodes:
http://www.quirksmode.org/dom/intro.html#nodes

The Document Object Model (DOM):
The Simple Document's Diagram
http://webreference.com/js/column40/drawsimple.html
(Reading the entire article is best)

DU

 

[Jim Ley]

Performance comparison between innerHTML attribute and DOM's nodeValue
when modifying the text data of a node of type TEXT_NODE:
http://www10.brinkster.com/doctorunclear/HTMLJavascriptCSS/innerHTMLvsNodeValue.html

You're assuming that speed matters.

You're also not doing any of the error trapping, to trap the
childNodes one you need to test for the existence of childNodes and of
childNodes[0], which you do not do this will further degrade
performance.

However in specific examples W3 DOM might be faster at the expense of
complexity and it's certainly worth using them with appropriate
checks, the problem is for the novice scripter understanding DOM and
ensuring it's safe isn't so easy, hence the OP's question.

Jim.

 

[DU]

You're assuming that speed matters.

I'm just noticing that speed is a little bonus on top of
interoperability and compliance to standards.
If you know what you're doing, then you no longer need to resort to
innerHTML (and innerText, etc...) anymore: one code fits all recent
browsers. It's not just modifying nodeValue but all the other
CharacterData methods as well (inserting, replacing, deleting,
appending) which are now very well supported by recent browser versions.

You're also not doing any of the error trapping, to trap the
childNodes one you need to test for the existence of childNodes and of
childNodes[0], which you do not do

Fair enough. I've updated the function with:
if(arrAllTheParg[PargIterator].childNodes[0] &&
arrAllTheParg[PargIterator].childNodes[0].nodeType == 3)
in the for loop.

this will further degrade

performance.

Not much degradation. Maybe 50msec to 100msec on my PC. It's still
considerably faster to use DOM nodeValue instead of innerHTML.
I changed the "300%" to "200%".

However in specific examples W3 DOM might be faster at the expense of
complexity and it's certainly worth using them with appropriate
checks, the problem is for the novice scripter understanding DOM and
ensuring it's safe isn't so easy, hence the OP's question.

Jim.

I would say that a majority of text changes in usual pages involve only
a few words, or a line, maybe a 2 line paragraph at the most (not 15KB
of text like in my testpage). In which case, using innerHTML or
firstChild.nodeValue or innerText (if applicable) won't make a lot of
difference in speed, performance.

DU

 

[Thomas 'PointedEars' Lahn]

It's often best to use the proprietary methods, as these generally are
optimised for scripting, and only fallback to DOM if they don't work.

This approach is utter nonsense as it makes scripts incompatible by
default, and we do not have to talk about their perspective to work
in the foreseeable future. Standards have been established to be
followed, not to be avoided. That is not a matter of whether you
like them or not, but a matter of getting dependent on the moods of
one particular vendor and his products, or not.


PointedEars

 

[Jim Ley]

This approach is utter nonsense as it makes scripts incompatible by
default,

incompatible with what by default, it's ludicrous to talk about
incompatibility without talking about what it it incompatible with.

There's no single solution that reaches 100% every solution is
incompatible with some user agents.

and we do not have to talk about their perspective to work
in the foreseeable future.

Most pages are written for the foreseeable future, in any case,
there's no new browsers on the horizon in the HTML world, and those
that exist and are being worked on are all implementing the same old
proprietary scripts.

The future holds much more chances of X-Smiles or DENG becoming more
important, and no HTML pages are going to be relevant, let alone their
scripting.

Standards have been established to be
followed, not to be avoided.

We've already established that some proprietary is ok to be used
(document, setTimeout etc. being the most relevant) if some is okay,
then you have to make explicit what the objective criteria you're
using to choose which are allowed and which aren't.

Jim.

 

[Thomas 'PointedEars' Lahn]

This approach is utter nonsense as it makes scripts incompatible by
default,

incompatible with what by default, it's ludicrous to talk about
incompatibility without talking about what it it incompatible with.[/QUOTE]

Incompatibility with other user agents, previous and future versions
of the same UA, versions of the same UA running on other platforms,
and other document types and thus other DOMs supported by the same UA.

There's no single solution that reaches 100% every solution is
incompatible with some user agents.

True, nevertheless proprietary code is error-prone code
and should be avoided where possible, not been looked for.


PointedEars

 

[Thomas 'PointedEars' Lahn]

We've already established that some proprietary is ok to be used
(document, setTimeout etc. being the most relevant) if some is okay,
then you have to make explicit what the objective criteria you're
using to choose which are allowed and which aren't.

There is a difference between "not allowed" and "not (to be)
recommended". I argued for the latter, *knowing* that one
sometimes is required to use proprietary code *additionally*
to accomplish something because a standard for the feature is
(still) missing (take graphics filters in CSS for example.)

Besides, I do not accept `document' being called proprietary in
general. It can be (and is in Mozilla/5.0) a way of implementing
the W3C-DOM interface to be practical. `document instanceof
Document' yields `true' and Document.constructor yields `[object
DOM Constructor.prototype]' in Mozilla/5.0, so AFAIS the Document
object in *this* UA implements what is specified in the W3C-DOM.
If M$ did not implement the W3C-DOM in this way (and so far I am
missing a Document object in IE), it is their problem.


PointedEars

 

[Lasse Reichstein Nielsen]

Besides, I do not accept `document' being called proprietary in
general.

What do you mean by "in general"? And, just to be clear, what do you
mean by the word "proprietary"?

The existence of a global variable called "document" is not part
of any W3C recommendation or standards body published standard.
For my definition of "proprietary", that makes that global
variable (a.k.a. property of the global object) proprietary.
The value of the variable is irrelevant.

/L

 

[Jim Ley]

Incompatibility with other user agents, previous and future versions
of the same UA, versions of the same UA running on other platforms,
and other document types and thus other DOMs supported by the same UA.

Firstly why is that a problem, you're using object detection, your
code won't error in these other systems, you're code degrades to
something usable if the method fails, all that is lost is that these
other browsers don't get your enhanced functionality.

It's probably worth choosing methods which give you the enhanced
functionality in many UA's, and many proprietrary methods can do this,
just like DOM ones.

There's an interesting argument in using proprietrary whereby you have
a lot smaller level of UA's to attempt authoring on, so if FredBrowser
6.5 has a broken DOM method which errors, it'll ignore your
proprietrary method, but use attempt the DOM one resulting in an
error. Proprietrary gives you a lot smaller test regime. Of course
FredBrowser and others which don't error won't get the enhanced
functionality, but that isn't a disaster.

True, nevertheless proprietary code is error-prone code

Could you explain what's error prone about it?

Jim.

 

[Thomas 'PointedEars' Lahn]

What do you mean by "in general"?

It does not apply for all UAs.

And, just to be clear, what do you mean by the word "proprietary"?

A feature not based upon standards in any way.

The existence of a global variable called "document" is not part
of any W3C recommendation or standards body published standard.

1. `document' is an instance of the Document object in Mozilla/5.0.

2. The Document object is defined in the W3C-DOM Level 2 ECMAScript
language binding.

3. JavaScript 1.5, as supported by Mozilla/5.0, is fully compatible
with ECMAScript 3.

4. Mozilla/5.0's Document object defines a prototype that has the
same properties as the Document object of the W3C DOM 2.

5. `document' is a way of implementing the W3C-DOM in this UA.
It is not a proprietary feature.

6. `document' in the DOM of the IE browser component is not based
upon the W3C-DOM Document object. It is a proprietary feature
in *this* UA.


PointedEars

 

[Lasse Reichstein Nielsen]

Lasse Reichstein Nielsen wrote:

It does not apply for all UAs.
Ok.


A feature not based upon standards in any way.
Agree.


1. `document' is an instance of the Document object in Mozilla/5.0.

No, 'document' is a string of eight characters.
When used in a Javascript program as a variable, it is (unless
declared by the user) a global variable, and as such refers to a
property of the global object.

*The existence of that variable* is not based on any standard.

The *variable* is prorietary. The object it refers to is not.

....

5. `document' is a way of implementing the W3C-DOM in this UA.
It is not a proprietary feature.

If I make a browser with no global "document" variable, but a global
variable was called "arglebargle" that refers to an object
implementing of the W3C DOM's Document interface ... would that be
proprietary?

If yes, so is the variable "document".
If no, why not?

/L