Changing text between <div>'s

[Thomas 'PointedEars' Lahn]

No,

Do I need to remember you that `document instanceof Document'
yields `true' *there*? It is indeed an instance of the Document
object *there*.

'document' is a string of eight characters.

It is an *identifier* consisting of eight characters.


PointedEars

 

[Lasse Reichstein Nielsen]

Do I need to remember you that `document instanceof Document' (remind)
yields `true' *there*? It is indeed an instance of the Document
object *there*.

Yes, the *value* that the variable refers to, is an instance of the
prototype of the function object referred to by the variable
"Document".

I was never talking about the value, just the variable itself.

It is an *identifier* consisting of eight characters.

Yes. When that string is used in a Javascript program, it is an
identifier. That identifier can then be a variableExpression.
That variableExpression will, when evaluated, be looked up as
a property of the global object. Whether that succedes is not
specified in any standard.

/L

 

[Jim Ley]

However it is in a current Working Draft. (not for an HTML UA though)

Do I need to remember you that `document instanceof Document'
yields `true' *there*? It is indeed an instance of the Document
object *there*.

So,

fred=evt.srcElement.ownerDocument;

makes fred an instanceOf Document too, it doesn't make fred standard,
it's just a variable, like document is. (the code's obviously only
relevant in certain situations.)

Jim.

 

[Thomas 'PointedEars' Lahn]

fred=evt.srcElement.ownerDocument;

makes fred an instanceOf Document too,

There is no Document object in the DOM of the IE browser
component. Can you name another UA where the above works
where there is a Document object?


PointedEars

 

[Jim Ley]

There is no Document object in the DOM of the IE browser
component.

Where did I mention IE?

Can you name another UA where the above works
where there is a Document object?

ASV, CSV, Batik...

Jim.

 

[Ton den Hartog]

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

That works. But what if I want a HTML element in the tag. When I use
"Hello<br>world" I get a LITERAL <br> in my browser-screen !! :-( How can I
prevent that ?

Ton

 

[Thomas 'PointedEars' Lahn]

That works. But what if I want a HTML element in the tag.

Not in the tag, in the _element_. You need to understand the difference
between these two before you do any DHTML.

When I use "Hello<br>world" I get a LITERAL <br> in my
browser-screen !! :-(

Of course. A text node is a _text_ node.

How can I prevent that ?

Use the W3C-DOM. Quickhack:

if (typeof document != "undefined" && document.getElementById)
{
var o = document.getElementById("t");
if (o)
{
o.firstChild.nodeValue = "Hello";
o.appendChild(document.createElement("br"));
o.appendChild(document.createTextNode("world"));
}
}

[Top post]

http://www.allmyfaqs.com/faq.pl?How_to_post


PointedEars

 

[Jim Ley]

That works. But what if I want a HTML element in the tag. When I use
"Hello<br>world" I get a LITERAL <br> in my browser-screen !! :-( How can I
prevent that ?

Then you have to do a lot more work and create a BR element and insert
it in the relevant place, then create a 2nd text node and add that
after it...

Much easier to just use innerHTML

if (document.getElementById) {
var t=document.getElementById('t');
if (t) {
t.innerHTML='hello<br>world';
}
}

Remember of course that no method works in 100% of browsers (and most
don't work in 60%) so it's always best to ensure that your content
works without javascript, and to ensure your javascript doesn't error
as much as possible.

Jim.

 

[Jim Ley]

Use the W3C-DOM. Quickhack:

if (typeof document != "undefined" && document.getElementById)
{
var o = document.getElementById("t");
if (o)
{

Generally it's a good idea if you're new to javascript to use

if (o) {

format, as you may well later be confused, see:

http://www.crockford.com/javascript/lint.html

o.firstChild.nodeValue = "Hello";

You'll also want to check
if (o.firstChild) {
o.firstChild.nodeValue="Hello";
}

o.appendChild(document.createElement("br"));

and
if (document.createElement && o.appendChild) {
o.appendChild(document.createElement("br"));
}

o.appendChild(document.createTextNode("world"));

and

if (document.createTextNodet && o.appendChild) {
o.appendChild(document.createTextNode("world"));
}

Since some of the methods aren't available in all user agents.

Jim.

 

[Thomas 'PointedEars' Lahn]

Generally it's a good idea if you're new to javascript to use

if (o) {

format,

I do not agree. Clearly indicating where a statement begins, where it
ends, where a block starts and where it ends, helps to understand the
structure of code, especially for beginners.

as you may well later be confused,
Nonsense.

see:

http://www.crockford.com/javascript/lint.html

You do not cite that as a reference for code style, do you?

I am not even convinced such a program is necessary or useful, since it
errors are best found at run time, when testing the code with different
hosts. Validating code with such only creates the temptation not to do
thorough testing "because the validator said it is OK."

o.firstChild.nodeValue = "Hello";

You'll also want to check
[...]
Since some of the methods aren't available in all user agents.

Funny, you should know that I am usually the one who
recommends to check for everything before using it:

http://pointedears.de.vu/scripts/test/whatami

Maybe that's why I called this a *quickhack* ...


shaking the head,
PointedEars

 

[Lasse Reichstein Nielsen]

PLEASE don't top post.

That works. But what if I want a HTML element in the tag. When I use
"Hello<br>world" I get a LITERAL <br> in my browser-screen !! :-( How can I
prevent that ?

If you want to use DOM methods;

var t = document.getElementById("t");
// clear content
while(t.hasChildNodes()) {
t.removeChild(t.lastChild);
}
// add new content:
t.appendChild(document.createTextNode("Hello"));
t.appendChild(document.createElement("br"));
t.appendChild(document.createTextNode("World"));

Search for the W3C DOM 2 specification to read more about dynamic
document manipulation.

/L

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in
Ton den Hartog <ton.den.hartog.removespam@ton
h.net> posted at Fri, 26 Dec 2003 11:34:27 :-

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>

Read the FAQ of the newsgroup, as posted Mon/Fri. That is item 4.15,
and section 2.3 will also help you in the correct formatting of
newsgroup replies.


Important points are that this task - div changing - is likely to be
required more than once, and so is best encapsulated in a function (as
in the FAQ) and that the details are browser-dependent, which is another
reason for encapsulation.

Just code it as DynWrite("t", "Hello") which makes the meaning
perfectly clear.

 

[DU]

Then you have to do a lot more work and create a BR element and insert
it in the relevant place, then create a 2nd text node and add that
after it...

Much easier to just use innerHTML

That's true: more

 work, slower also (according to tests) with
HTML nodes created on the fly (1). I still do not think people should be
using innerHTML when they want to change a simple text node.

DU
(1) Even MSDN sets limits to the usefulness and performance of innerHTML
property, suggesting to use innerText when targeted nodes are text nodes.
More Performance Tips, October 4, 1999
"(...) By now, almost everyone knows that using element.innerHTML is
slow, slow, slow. To see just how slow it was, I made a final test page
that used innerHTML instead of innerText to insert "Text" into the cell.
This literally crushed performance."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndude/html/dude100499.asp

 

[DU]

JRS: In article <[email protected]>, seen in
Ton den Hartog <ton.den.hartog.removespam@ton
h.net> posted at Fri, 26 Dec 2003 11:34:27 :-




Read the FAQ of the newsgroup, as posted Mon/Fri. That is item 4.15,
and section 2.3 will also help you in the correct formatting of
newsgroup replies.


Important points are that this task - div changing - is likely to be
required more than once, and so is best encapsulated in a function (as
in the FAQ) and that the details are browser-dependent, which is another
reason for encapsulation.

Just code it as DynWrite("t", "Hello") which makes the meaning
perfectly clear.

I have a problem with item 4.15 when one needs to change only the text
of a text node (and this is the case with the OP). Resorting to
innerHTML as clearly proposed by item 4.15 is not best, not the most
efficient and not complying with DOM 2 Core. A very wide majority of
users are using browsers which support perfectly each and all of
CharacterData methods. Therefore, IMO, the FAQ should be updated to
reflect this.

How about:

<div id="idDiv">previous text</div>

could be modified with the code:

if(document.getElementById("idDiv").firstChild &&
document.getElementById("idDiv").firstChild.nodeType == 3)
{
document.getElementById("idDiv").firstChild.nodeValue = "New text
replacing previous text";
};

DU

 

[DU]

Jim Ley wrote:

[snipped]

Generally it's a good idea if you're new to javascript to use

if (o) {

format, as you may well later be confused, see:

http://www.crockford.com/javascript/lint.html

[snipped]

Jim, can you elaborate a bit of this brace format thing. I went to the
given url and only could find these words as *possibly* related to what
you're saying:

"Forbidden Blocks: (...) In JavaScript, blocks do not introduce a scope.
There is only function-scope. JavaScript's blocks confuse experienced
programmers and lead to errors."

I still do not understand how or why that particular format of creating
block would not make me confused; I don't understand.

I prefer to have the curly braces on the same column (and with indenting
nested ones) because this makes blocks of code easy to figure out (where
they start and where they end).
This issue may be not related to the OP but it sure is a matter of most
suitable coding practices.

This format:
if(boolean condition)
{
....
};
is easy to read.

That format:
if(boolean condition) {
....
};
does not help code readability.


DU

 

[Lasse Reichstein Nielsen]

This format:
if(boolean condition)
{
...
};
is easy to read.

That format:
if(boolean condition) {
...
};
does not help code readability.

That is obviosuly completely personal. I have it exactly the opposite way.

I want the start of the block to be on the same line as the statement
keyword that uses it, not on the next line. It confuzes me when the
block seems to have no connection to the if statement.
The indentation takes care of showing what belongs to the block, so
I can just look at the end brace and find the preceding line with the
same indentation, to find the line where it starts.

/L

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in

I have a problem with item 4.15 when one needs to change only the text
of a text node (and this is the case with the OP). Resorting to
innerHTML as clearly proposed by item 4.15 is not best, not the most
efficient and not complying with DOM 2 Core. A very wide majority of
users are using browsers which support perfectly each and all of
CharacterData methods. Therefore, IMO, the FAQ should be updated to
reflect this.

How about:

<div id="idDiv">previous text</div>

could be modified with the code:

if(document.getElementById("idDiv").firstChild &&
document.getElementById("idDiv").firstChild.nodeType == 3)
{
document.getElementById("idDiv").firstChild.nodeValue = "New text
replacing previous text";
};

The purpose for which, IIRC, 4.15 was written was to enable the same
page to work in three major types of browser - for example, NS4.7,
MSIE4, and later. It turned out that the NS4.7 case, while IIRC
soluble, was difficult to deal with, in the matter of explaining
when/where a writeable region could be planted; it has been dropped.

Your code appears grievously defective, in that it works only in
browsers with getElementbyID, and where there is a first child of type
3; if there is no such child it fails silently, and if there is no
getElementbyID it crashes.

If put in the FAQ, any limitations need to be clearly noted, especially
for silent failure.


Moreover, one should not recommend to others code such as the above.
The code should be used by the modular form Func(Dest, String) ; with
the workings nicely encapsulated in Func, which can be defined earlier
in the page or in an include file.


But if your code is included in such a function as 4.15 gives, in a
manner such that it can never fail silently, then I can readily believe
that it could be useful.


Web pages need to be designed, by US & UK law where applicable, to be
adequately accessible to the physically disabled. They should also be
designed to be accessible to the fiscally disabled, for example in the
Third World and in the American backwoods, where it may be necessary to
continue with older systems. Admittedly IIRC the US Act, judged by
title, only favours disabled Americans; but the UK Act is not similarly
restrictive.


.... I don't want details; but do other EU countries have legislation
similar to the UK Disability Discrimination Act(s)?

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in

I want the start of the block to be on the same line as the statement
keyword that uses it, not on the next line. It confuzes me when the
block seems to have no connection to the if statement.
The indentation takes care of showing what belongs to the block, so
I can just look at the end brace and find the preceding line with the
same indentation, to find the line where it starts.

One needs first to decide exactly what the indentation is going to be
used for.

IMHO, manual indentation cannot be used to show structure in a page that
is being written; it can only show intended structure, which is a
distinct concept.

If the page is indented by a program, which understands sufficient of
the rules of the language but nothing of the author's intent, then it
shows the actual structure. This is very useful, if achievable (I wrote
a Pascal program to do it for Pascal); if the author sees, where no
indentation was expected, either positive or negative indentation, then
he has received useful information.

Once the page is structurally correct, of course, the above layout
algorithms come into agreement.

My own preference is for the indentation of the first inky character of
a line to depend only on the content of previous lines, and to be one
level for each open structure plus one level if the new line breaks a
statement. But that is partly the result of years of using layout tools
that give that (I wrote an earlier Algol version that indented Algol
thusly, *and* put one null before and three nulls after every CRLF on
the output eight-hole tape).

 

[DU]

JRS: In article <[email protected]>, seen in




The purpose for which, IIRC, 4.15 was written was to enable the same
page to work in three major types of browser - for example, NS4.7,
MSIE4, and later. It turned out that the NS4.7 case, while IIRC
soluble, was difficult to deal with, in the matter of explaining
when/where a writeable region could be planted; it has been dropped.

Your code appears grievously defective, in that it works only in
browsers with getElementbyID

Yes. I intentionally do not wish to write more javascript code to
support browsers which do not support getElementById. That's per webpage
[specification] requirements; that my policy - one day, people have
to/should/should be invited to/must upgrade. Now, roughly 96% of all
browsers in use out there support document.getElementById.

, and where there is a first child of type

3; if there is no such child it fails silently,

If there is no first child of type 3, then it means there is no text
node as first child and the function should end there. That's on purpose.

and if there is no

getElementbyID it crashes.

It will not work for about 4% of browsers in use out there. In which
case, normal accessibility fallback mechanisms should take over. In any
case of webpage design, checking how a page behaves, functions, manages
without javascript support enabled is a sane and necessary task to do.

If put in the FAQ, any limitations need to be clearly noted, especially
for silent failure.

I kinda agree with you but I think the FAQ should not be an endless
tutorial on how to do professional webpages. There is a limit to what
should be answered, explained, described in a FAQ. People are annoyed by
lengthy FAQ. There is no limitations set or any kind of implicit or
explicit constraint in letting users search for answers by themselves:
searching tutorials, columns, lurking in newsgroups, etc..
Whatever item 4.15 uses, there will be silent failures for any kind of
code (e.g. MSN-TV does not support innerHTML).

Moreover, one should not recommend to others code such as the above.

I was merely submitting the relevant working code in a discussion
newsgroup. As far as I'm concerned, item 4.15 as written (explanations
and code) is not easy to understand, is not recommendable as it is and
is definitively improvable.

The code should be used by the modular form Func(Dest, String) ; with
the workings nicely encapsulated in Func, which can be defined earlier
in the page or in an include file.

Modularizing the code was not the main point of my reply. Of course,
modularization of code is always better and brings lots of benefits. And
modularization of my code would be very easy to do. If item 4.15 aims at
educating newbies on proper and best coding practices, then it should
offer an answer where the code is modularized too: I don't even see that
right now. Do you?

But if your code is included in such a function as 4.15 gives,

I don't see a clear, easy to grasp, straightforward, easy-to-implement
function in 4.15. I think 4.15 should be entirely re-written.

in a

manner such that it can never fail silently, then I can readily believe
that it could be useful.

It is not my goal to write a function that never fails silently. I think
such goal for any kind of script function is unrealistic to begin with.

DU

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in

Dr John Stockton wrote:

Your code appears grievously defective, in that it works only in
browsers with getElementbyID

Yes. I intentionally do not wish to write more javascript code to
support browsers which do not support getElementById. That's per webpage
[specification] requirements; that my policy - one day, people have
to/should/should be invited to/must upgrade. Now, roughly 96% of all
browsers in use out there support document.getElementById.

You may choose to do that in your own work - it might well be considered
in breach of the spirit of ADA / DAA, where applicable - but it is not
right to lead others to do it without warning of limitations known to
you.

, and where there is a first child of type

If there is no first child of type 3, then it means there is no text
node as first child and the function should end there. That's on purpose.

The programmer, then, has attempted to do the impossible. A warning of
some sort needs to be given; it may well be that the string-writing is
essential but inadvertently mis-aimed. A silent failure is too easily
missed on test, and is liable to be missed in real use.

There is a limit to what
should be answered, explained, described in a FAQ. People are annoyed by
lengthy FAQ. There is no limitations set or any kind of implicit or
explicit constraint in letting users search for answers by themselves:
searching tutorials, columns, lurking in newsgroups, etc..

The whole point of a newsgroup FAQ is to make that unnecessary. By
searching, one can find any number of answers, many of which more-or-
less work, usually. In an actively-edited newsgroup FAQ, one finds
reviewed good-practice answers; one can expect any limitations to be
noted.

Whatever item 4.15 uses, there will be silent failures for any kind of
code (e.g. MSN-TV does not support innerHTML).

Jim? Does that give a silent failure? If do, can that be fixed, or is
MSN-TV an unreasonably inadequate system?

Modularizing the code was not the main point of my reply. Of course,
modularization of code is always better and brings lots of benefits. And
modularization of my code would be very easy to do. If item 4.15 aims at
educating newbies on proper and best coding practices, then it should
offer an answer where the code is modularized too: I don't even see that
right now. Do you?

Indeed so; one executes the code once (so it need not be made into a
function) and after that one just calls DynWrite('DivID', 'String') when
needed.

I don't see a clear, easy to grasp, straightforward, easy-to-implement
function in 4.15. I think 4.15 should be entirely re-written.

When upgrading my <URL:http://www.merlyn.demon.co.uk/holidays.htm>, I
copy'n'pasted the code from the FAQ into the page, correcting only the
superfluous first space character. Using a div and a DynWrite call as
described immediately above in the FAQ, it worked immediately. I don't
see what greater ease could be wished for.

One does, I grant, need to get used to Jim's style of writing the bodies
of FAQ entries; but that applied to any technical document not
professionally sub-edited.

in a

It is not my goal to write a function that never fails silently. I think
such goal for any kind of script function is unrealistic to begin with.

Perhaps it is impossible to achieve silent failure in all cases. But
predictable silent failure should never be permitted. Consider the case
of a silently failing attempt to insert "NOT" into the div here -

<p>You must <div ID=X2334>now</div> do that!