Changing text between <div>'s

[Lasse Reichstein Nielsen]

Re: Changing text between &lt;div&gt;' s

"Ton den Hartog" <ton.den.hartog .removespam@ton h.net> writes:

PLEASE don't top post.
[color=blue][color=green]
>> document.getEle mentById('t').f irstChild.nodeV alue="Hello";[/color]
>
> 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 ?[/color]

If you want to use DOM methods;

var t = document.getEle mentById("t");
// clear content
while(t.hasChil dNodes()) {
t.removeChild(t .lastChild);
}
// add new content:
t.appendChild(d ocument.createT extNode("Hello" ));
t.appendChild(d ocument.createE lement("br"));
t.appendChild(d ocument.createT extNode("World" ));

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

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[DU]

Re: Changing text between &lt;div&gt;' s

Jim Ley wrote:
[color=blue]
> On Sun, 28 Dec 2003 02:41:35 +0100, "Ton den Hartog"
> <ton.den.hartog .removespam@ton h.net> wrote:
>
>[color=green][color=darkred]
>>> document.getEle mentById('t').f irstChild.nodeV alue="Hello";[/color]
>>
>>That works. But what if I want a HTML element in the tag. When I use
>>"Hello<br>wor ld" I get a LITERAL <br> in my browser-screen !! :-( How can I
>>prevent that ?[/color]
>
>
> 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[/color]

That's true: more [code] 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.innerHT ML 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

[color=blue]
>
> if (document.getEl ementById) {
> var t=document.getE lementById('t') ;
> if (t) {
> t.innerHTML='he llo<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.[/color]

[Dr John Stockton]

Re: Changing text between &lt;div&gt;' s

JRS: In article <3fec0eb5$0$321 $e4fe514c@news. xs4all.nl>, seen in
news:comp.lang. javascript, Ton den Hartog <ton.den.hartog .removespam@ton
h.net> posted at Fri, 26 Dec 2003 11:34:27 :-[color=blue]
>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.val ue="Hello"
>
>should change it into
>
><div id="t">Hello</div>[/color]


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.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[DU]

Re: Changing text between &lt;div&gt;' s

Dr John Stockton wrote:[color=blue]
> JRS: In article <3fec0eb5$0$321 $e4fe514c@news. xs4all.nl>, seen in
> news:comp.lang. javascript, Ton den Hartog <ton.den.hartog .removespam@ton
> h.net> posted at Fri, 26 Dec 2003 11:34:27 :-
>[color=green]
>>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.va lue="Hello"
>>
>>should change it into
>>
>><div id="t">Hello</div>[/color]
>
>
>
> 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.
>[/color]


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">prev ious text</div>

could be modified with the code:

if(document.get ElementById("id Div").firstChil d &&
document.getEle mentById("idDiv ").firstChild.n odeType == 3)
{
document.getEle mentById("idDiv ").firstChild.n odeValue = "New text
replacing previous text";
};

DU

[DU]

Re: Changing text between &lt;div&gt;' s

Jim Ley wrote:

[snipped]
[color=blue]
>
>
> 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
>
>[/color]

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

Re: Changing text between &lt;div&gt;' s

DU <drunclear@hotR EMOVETHISmail.c om> writes:
[color=blue]
> This format:
> if(boolean condition)
> {
> ...
> };
> is easy to read.
>
> That format:
> if(boolean condition) {
> ...
> };
> does not help code readability.[/color]

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
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Dr John Stockton]

Re: Changing text between &lt;div&gt;' s

JRS: In article <bspllv$7s6$1@n ews.eusc.inter. net>, seen in
news:comp.lang. javascript, DU <drunclear@hotR EMOVETHISmail.c om> posted
at Mon, 29 Dec 2003 11:44:37 :-[color=blue]
>
>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
>CharacterDat a methods. Therefore, IMO, the FAQ should be updated to
>reflect this.
>
>How about:
>
><div id="idDiv">prev ious text</div>
>
>could be modified with the code:
>
>if(document.ge tElementById("i dDiv").firstChi ld &&
>document.getEl ementById("idDi v").firstChild. nodeType == 3)
>{
>document.getEl ementById("idDi v").firstChild. nodeValue = "New text
>replacing previous text";
>};[/color]


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)?

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Dr John Stockton]

Re: Changing text between &lt;div&gt;' s

JRS: In article <ekunjxk1.fsf@h otpop.com>, seen in
news:comp.lang. javascript, Lasse Reichstein Nielsen <lrn@hotpop.com >
posted at Mon, 29 Dec 2003 19:20:14 :-[color=blue]
>
>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.[/color]


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

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demo n.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.

[DU]

Re: Changing text between &lt;div&gt;' s

Dr John Stockton wrote:
[color=blue]
> JRS: In article <bspllv$7s6$1@n ews.eusc.inter. net>, seen in
> news:comp.lang. javascript, DU <drunclear@hotR EMOVETHISmail.c om> posted
> at Mon, 29 Dec 2003 11:44:37 :-
>[color=green]
>>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
>>CharacterDa ta methods. Therefore, IMO, the FAQ should be updated to
>>reflect this.
>>
>>How about:
>>
>><div id="idDiv">prev ious text</div>
>>
>>could be modified with the code:
>>
>>if(document.g etElementById(" idDiv").firstCh ild &&
>>document.getE lementById("idD iv").firstChild .nodeType == 3)
>>{
>>document.getE lementById("idD iv").firstChild .nodeValue = "New text
>>replacing previous text";
>>};[/color]
>
>
>
> 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[/color]

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.getEle mentById.

, and where there is a first child of type[color=blue]
> 3; if there is no such child it fails silently,[/color]

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[color=blue]
> getElementbyID it crashes.
>[/color]

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.
[color=blue]
> If put in the FAQ, any limitations need to be clearly noted, especially
> for silent failure.
>
>[/color]

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).
[color=blue]
> Moreover, one should not recommend to others code such as the above.[/color]

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.
[color=blue]
> 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.
>[/color]

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?
[color=blue]
>
> But if your code is included in such a function as 4.15 gives,[/color]

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[color=blue]
> manner such that it can never fail silently, then I can readily believe
> that it could be useful.
>[/color]

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
[color=blue]
>
> 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)?
>[/color]

[Dr John Stockton]

Re: Changing text between &lt;div&gt;' s

JRS: In article <bssa4q$51g$1@n ews.eusc.inter. net>, seen in
news:comp.lang. javascript, DU <drunclear@hotR EMOVETHISmail.c om> posted
at Tue, 30 Dec 2003 11:46:19 :-[color=blue]
>Dr John Stockton wrote:[/color]
[color=blue][color=green]
>> Your code appears grievously defective, in that it works only in
>> browsers with getElementbyID[/color]
>
>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.getEle mentById.[/color]

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.

[color=blue]
>, and where there is a first child of type[color=green]
>> 3; if there is no such child it fails silently,[/color]
>
>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.[/color]

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.



[color=blue]
> 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..[/color]

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.


[color=blue]
>Whatever item 4.15 uses, there will be silent failures for any kind of
>code (e.g. MSN-TV does not support innerHTML).[/color]

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

[color=blue][color=green]
>> 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.
>>[/color]
>
>Modularizing the code was not the main point of my reply. Of course,
>modularizati on of code is always better and brings lots of benefits. And
>modularizati on 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?[/color]

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.

[color=blue][color=green]
>> But if your code is included in such a function as 4.15 gives,[/color]
>
>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.[/color]

When upgrading my <URL:http://www.merlyn.demo n.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.
[color=blue]
>in a[color=green]
>> manner such that it can never fail silently, then I can readily believe
>> that it could be useful.
>>[/color]
>
>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.[/color]


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!


--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[DU]

Re: Changing text between &lt;div&gt;' s

Dr John Stockton wrote:
[color=blue]
> JRS: In article <bssa4q$51g$1@n ews.eusc.inter. net>, seen in
> news:comp.lang. javascript, DU <drunclear@hotR EMOVETHISmail.c om> posted
> at Tue, 30 Dec 2003 11:46:19 :-
>[color=green]
>>Dr John Stockton wrote:[/color]
>
>[color=green][color=darkred]
>>>Your code appears grievously defective, in that it works only in
>>>browsers with getElementbyID[/color]
>>
>>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.getEle mentById.[/color]
>
>
> You may choose to do that in your own work - it might well be considered
> in breach of the spirit of ADA / DAA,[/color]

ADA / DAA: I'm getting more and more annoyed by acronyms and
abbreviations of all sorts here and there. What do these refer to?

Browsers which do not support getElementById are as far I'm concerned
somewhat defective, are not compliant with W3C web standards and
certainly need to be upgraded.

where applicable - but it is not[color=blue]
> right to lead others to do it without warning of limitations known to
> you.
>
>[/color]

Can you elaborate on what would be in your opinion a sufficient warning
of limitation in such script? Can you give a full example of what you
have been supporting, defending?
[color=blue]
>[color=green]
>>, and where there is a first child of type
>>[color=darkred]
>>>3; if there is no such child it fails silently,[/color]
>>
>>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.[/color]
>
>
> The programmer, then, has attempted to do the impossible.[/color]

I don't understand what you wrote here and why you wrote that. The
function checks the first node and if it is not a text node, then
nothing is done because nothing should be done in such case. You say my
function fails: I would say it works precisely and accordingly. <shrug>

A warning of[color=blue]
> 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.
>[/color]

If document.getEle mentById is not supported, then what are you proposing
should be the warning? and how to report such warning to the user? via
an alert?
[color=blue]
>
>
>
>[color=green]
>>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..[/color]
>
>
> The whole point of a newsgroup FAQ is to make that unnecessary.[/color]

Could you have a look at that newsgroup FAQ, in particular the whole
section 3 then? Are you suggesting that we should remove section 3 of
the FAQ?
May I repeat here what I already wrote in this thread:

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)

By[color=blue]
> 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.
>
>
>
>[color=green]
>>Whatever item 4.15 uses, there will be silent failures for any kind of
>>code (e.g. MSN-TV does not support innerHTML).[/color]
>
>
> Jim? Does that give a silent failure? If do, can that be fixed, or is
> MSN-TV an unreasonably inadequate system?
>
>[/color]

Why stop to MSN-TV? How about NS 4.x? How about IE 4? These 2 browsers
were designed more than 7 years ago. And there are a lot of free,
modern, much better, available alternatives to these browsers or much
newer versions. Why is it that script code should be longer/bigger/more
bloated because it should always try to cater for these old and
non-compliant browsers which do not represent 1% of all users out there?

Checking for object support, method support, property support makes
sense when such support is not universal or is known to be partially
supported in current browsers in use. getElementById is widely supported
in recent browsers; it's not supported in old browsers. Being exhaustive
in cases such as getElementById equate to creating bloated code and
conforting people into not upgrading to a W3C web standards compliant
browser.
[color=blue]
>[color=green][color=darkred]
>>>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.
>>>[/color]
>>
>>Modularizin g the code was not the main point of my reply. Of course,
>>modularizatio n of code is always better and brings lots of benefits. And
>>modularizatio n 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?[/color]
>
>
> 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.
>[/color]

Are you actually saying that the given code in item 4.15 is currently
modularized?
[color=blue]
>
>[color=green][color=darkred]
>>>But if your code is included in such a function as 4.15 gives,[/color]
>>
>>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.[/color]
>
>
> When upgrading my <URL:http://www.merlyn.demo n.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.
>
>[color=green]
>>in a
>>[color=darkred]
>>>manner such that it can never fail silently, then I can readily believe
>>>that it could be useful.
>>>[/color]
>>
>>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.[/color]
>
>
>
> Perhaps it is impossible to achieve silent failure in all cases. But
> predictable silent failure should never be permitted.[/color]

Can you give an example (script code) of what would be acceptable within
your line of thinking (minimize silent failure occurences) in cases such
as getElementById?

Consider the case[color=blue]
> of a silently failing attempt to insert "NOT" into the div here -
>
> <p>You must <div ID=X2334>now</div> do that!
>
>[/color]

I would use an alert call for such scenario or server side include... it
would depend on the whole page context.

DU

[Dr John Stockton]

Re: Changing text between &lt;div&gt;' s

JRS: In article <bsv0b2$1df$1@n ews.eusc.inter. net>, seen in
news:comp.lang. javascript, DU <drunclear@hotR EMOVETHISmail.c om> posted
at Wed, 31 Dec 2003 12:17:24 :-[color=blue]
>Dr John Stockton wrote:[/color]
[color=blue][color=green]
>> You may choose to do that in your own work - it might well be considered
>> in breach of the spirit of ADA / DAA,[/color]
>
>ADA / DAA: I'm getting more and more annoyed by acronyms and
>abbreviation s of all sorts here and there. What do these refer to?[/color]

You are an American programmer and you do not know of ADA, your own
applicable legislation? DAA is a typo for DDA, the corresponding UK
Act.

[color=blue]
>Browsers which do not support getElementById are as far I'm concerned
>somewhat defective, are not compliant with W3C web standards and
>certainly need to be upgraded.
>
>where applicable - but it is not[color=green]
>> right to lead others to do it without warning of limitations known to
>> you.[/color]
>
>Can you elaborate on what would be in your opinion a sufficient warning
>of limitation in such script? Can you give a full example of what you
>have been supporting, defending?[/color]


Read more thoughtfully; we are discussing what you wrote in the
newsgroup; and the warning should have been written in the article.

"This code fails, without giving any indication, in browsers without
getElementbyID. " would have sufficed. Or, in the code,
else alert("WriteFai l")
to go with the 'if'.


Code should preferably be infallible, and therefore incapable of giving
warnings or errors. Otherwise, instead of failing silently, give an
alert, a pop-op, or other visible indication.

[color=blue][color=green][color=darkred]
>>>, 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.[/color][/color][/color]

But the programmer has attempted to write there. Therefore, the output
is not as intended; error.

[color=blue][color=green]
>> The programmer, then, has attempted to do the impossible.[/color]
>
>I don't understand what you wrote here and why you wrote that. The
>function checks the first node and if it is not a text node, then
>nothing is done because nothing should be done in such case. You say my
>function fails: I would say it works precisely and accordingly. <shrug>[/color]

If nothing should be done, then code should not be executed.
[color=blue]
> A warning of[color=green]
>> 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.
>>[/color]
>
>If document.getEle mentById is not supported, then what are you proposing
>should be the warning? and how to report such warning to the user? via
>an alert?[/color]

Perhaps inelegant; but better than nothing. If the page design really
needs that facility, it may be better to show a different page.

[color=blue][color=green][color=darkred]
>>>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..[/color]
>>
>>
>> The whole point of a newsgroup FAQ is to make that unnecessary.[/color]
>
>Could you have a look at that newsgroup FAQ, in particular the whole
>section 3 then? Are you suggesting that we should remove section 3 of
>the FAQ?[/color]

No; section 3 is useful because it holds selected references; ones that
Jim has presumably looked at and considered to be worthwhile. In going
to those references, one is not searching; one has been told where to
look.



[color=blue]
>Why stop to MSN-TV? How about NS 4.x? How about IE 4? These 2 browsers
>were designed more than 7 years ago. And there are a lot of free,
>modern, much better, available alternatives to these browsers or much
>newer versions. Why is it that script code should be longer/bigger/more
>bloated because it should always try to cater for these old and
>non-compliant browsers which do not represent 1% of all users out there?[/color]

That's rather a Merkin attitude.

While the latest browser software does not require purchase, it uses
machine resources which may not be available on older machines. In the
third world, and even in the American boonies, such resources cannot
always be afforded.


[color=blue][color=green]
>> 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.
>>[/color]
>
>Are you actually saying that the given code in item 4.15 is currently
>modularized?[/color]

Not that it is itself modularised; but that it supports modular coding.
It defines a function, such that subsequently the coder has only to say
what is to be done (DynWrite), where (id), and with what (S). Once the
coder has caused the code in the box to be executed, he need have no
further concern with the mechanism.


Your own code must be executed everywhere that a string is written into
a div; AFAICS, it has only two varying parts, the destination and the
string, and so it could be used as the body of, say,
function DUwrite(id, S) { ... }

Now the aforementioned alert can cheaply be
alert("Writefai l\n"+S)

Naive programmers, and we see plenty of those here, have little
understanding of the proper use of functions; it is well to set a good
example.


[color=blue]
>Can you give an example (script code) of what would be acceptable within
>your line of thinking (minimize silent failure occurences) in cases such
>as getElementById?
>
> Consider the case[color=green]
>> of a silently failing attempt to insert "NOT" into the div here -
>>
>> <p>You must <div ID=X2334>now</div> do that!
>>
>>[/color]
>
>I would use an alert call for such scenario or server side include... it
>would depend on the whole page context.[/color]

Why need I give an example when you obviously can do so yourself?

In avoiding silent failure, there are two alternatives : avoid silence,
or avoid failure.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Jim Ley]

Re: Changing text between &lt;div&gt;' s

On Tue, 30 Dec 2003 20:25:25 +0000, Dr John Stockton
<spam@merlyn.de mon.co.uk> wrote:
[color=blue][color=green]
>>Whatever item 4.15 uses, there will be silent failures for any kind of
>>code (e.g. MSN-TV does not support innerHTML).[/color]
>
>Jim? Does that give a silent failure? If do, can that be fixed, or is
>MSN-TV an unreasonably inadequate system?[/color]

The method to detect that an assignment to innerHTML isn't easy and a
little confusing*, so reliably returning true/false on it is certainly
beyond a FAQ answer unfortunately 4.15 has already been simplified
once, it might be nice to simplify it down even further.

Silent failures are always going to happen in scripting I think, and
it's a good idea to try and author with this in mind, rather than try
an cope with every failure to a non-silent one.
[color=blue]
>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
>professional ly sub-edited.[/color]

I've not been around much in the last year (I was travelling for the
first 8 months and have since been trying to make the bank manager
smile at me again.) and the FAQ certainly needs updating, I'm busy
right now for a couple more months.

I am however more than willing to give anyone here with a reputation
in the group a login to the box, and therefore the ability to edit the
FAQ, including running the wscript script I currently use. Of course
an editor would be good. The editors I do know say I have some of the
worst grammar they've ever seen, so I'm pretty sure I'm not the best
person.

Cheers,

Jim.
[*] My brief thoughts are:

foo="<sTroNg >test</sTronG >";
someDiv.innerHT ML=foo;
innerHTMLWorks= !(foo==someDiv. innerHTML);

and

'<strong id=chicken>test </strong>
followed by a getElementById or equivalent.

but I'm sure both could be shown false in certain circumstances.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Dr John Stockton]

Re: Changing text between &lt;div&gt;' s

JRS: In article <3ff4b975.20010 103@news.cis.df n.de>, seen in
news:comp.lang. javascript, Jim Ley <jim@jibbering. com> posted at Fri, 2
Jan 2004 13:17:07 :-[color=blue]
>On Tue, 30 Dec 2003 20:25:25 +0000, Dr John Stockton
><spam@merlyn.d emon.co.uk> wrote:
>[color=green][color=darkred]
>>>Whatever item 4.15 uses, there will be silent failures for any kind of
>>>code (e.g. MSN-TV does not support innerHTML).[/color]
>>
>>Jim? Does that give a silent failure? If do, can that be fixed, or is
>>MSN-TV an unreasonably inadequate system?[/color]
>
>The method to detect that an assignment to innerHTML isn't easy and a
>little confusing*, so reliably returning true/false on it is certainly
>beyond a FAQ answer unfortunately 4.15 has already been simplified
>once, it might be nice to simplify it down even further.[/color]


if (document.all && !document.getEl ementById) {
document.getEle mentById = function(id) { // Randy
return document.all[id] } }

was posted here within the last few months. Does it provide a reliable
alternative?
[color=blue]
>Silent failures are always going to happen in scripting I think, and
>it's a good idea to try and author with this in mind, rather than try
>an cope with every failure to a non-silent one.[/color]


I don't see how one can in general cope with computed material that may
not appear, unless some sort of warning is shown.

Can one deal with the matter reliably along the lines of

<div ID=test align=center><B IG> <!-- HTML -->
So long as this text remains, the provision for writing
necessary material to this page cannot be presumed to be
working.
<br>YOU HAVE BEEN WARNED</BIG></div>

SomeWrite("ID", "All seems well") // javascript

?

OTOH, in a case like my holidays.htm, which has "Tabulate" buttons with
a definite implication that they should do something, perhaps no more is
needed than an indication of where something should happen.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

[HikksNotAtHome]

Re: Changing text between &lt;div&gt;' s

In article <ZlQqVqAcjc9$Ew Nu@merlyn.demon .co.uk>, Dr John Stockton
<spam@merlyn.de mon.co.uk> writes:
[color=blue][color=green]
>>
>>The method to detect that an assignment to innerHTML isn't easy and a
>>little confusing*, so reliably returning true/false on it is certainly
>>beyond a FAQ answer unfortunately 4.15 has already been simplified
>>once, it might be nice to simplify it down even further.[/color]
>
>
> if (document.all && !document.getEl ementById) {
> document.getEle mentById = function(id) { // Randy
> return document.all[id] } }
>
>was posted here within the last few months. Does it provide a reliable
>alternative?[/color]

While I am gracious to have my name mentioned in it, I can't claim credit for
it. It came from the metallusions website, I only stumbled on it (IIRC, someone
else pointed me to it).

<URL: http://www.metalusions.com/backstage/articles/8/ />


But all the code does is make getElementById semi-work in IE4 by returning a
reference to document.all[element] when document.getEle mentById(elemen t) is
called.
I think what Jim is referring to is attempting to test that inserting innerHTML
actually works is nearly impossible to do.
The closest he came was to suggest comparing an elements innerHTML (after
attempting to change it) to what you tried to insert. Consider:


function insertHTML(){
document.getEle mentById('myDiv ').innerHTML =
"<table><tr ></td>Some Sample innerHTML</td></tr></table>";
document.myForm .myTextArea.val ue =
document.getEle mentById('myDiv ').innerHTML;
}

<div id="myDiv"></div>
<form name="myForm">
<textarea name="myTextAre a" rows="5" cols="80"></textarea>
</form>

IE6.0 gives:

<TABLE>
<TBODY>
<TR></TD>Some Sample innerHTML</TD></TR></TBODY></TABLE>

With those line breaks.

Mozilla Firebird 0.7 gives:

<table><tbody>< tr>Some Sample innerHTML</tr></tbody></table>

With no line breaks but no TD tags.

Neither of which will match the original code. The only way to try to match
them is to check every known browser, see what it puts in the textarea, and
then do browser detection to try to find out what browser so you can determine
what string it should match.

Another alternative might be to compare the previous innerHTML to the latter
innerHTML though. If they don't match, then it didn't work:

function insertHTML(elem ,newHTML){
tempVar = document.getEle mentById(elem). innerHTML;
document.getEle mentById(elem). innerHTML = newHTML;
if (tempVar == document.getEle mentById(elem). innerHTML) {alert('It failed')}
}

Then, its comparing its own rendering against its own rendering. If they match,
then the attempt to change it failed.

Thoughts?
--
Randy