Changing text between <div>'s

[DU]

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,

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

right to lead others to do it without warning of limitations known to
you.

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?

The programmer, then, has attempted to do the impossible.

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

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.

If document.getElementById is not supported, then what are you proposing
should be the warning? and how to report such warning to the user? via
an alert?

The whole point of a newsgroup FAQ is to make that unnecessary.

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

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.






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

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.

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.

Are you actually saying that the given code in item 4.15 is currently
modularized?

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.





Perhaps it is impossible to achieve silent failure in all cases. But
predictable silent failure should never be permitted.

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

of a silently failing attempt to insert "NOT" into the div here -

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

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]

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

Dr John Stockton wrote:

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

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.

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

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?

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("WriteFail")
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.


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

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>

If nothing should be done, then code should not be executed.

A warning of

If document.getElementById is not supported, then what are you proposing
should be the warning? and how to report such warning to the user? via
an alert?

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

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?

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.

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?

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.

Are you actually saying that the given code in item 4.15 is currently
modularized?

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("Writefail\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.

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

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

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.

 

[Jim Ley]

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

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.

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.

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.innerHTML=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.

 

[Dr John Stockton]

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

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.

if (document.all && !document.getElementById) {
document.getElementById = function(id) { // Randy
return document.all[id] } }

was posted here within the last few months. Does it provide a reliable
alternative?

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.

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><BIG> <!-- 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.

 

[Lasse Reichstein Nielsen]

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

It is a fairly obvious approach. I have several different versions
of user-defined getElementById methods (and addEventListener is a
personal favorite too).

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

You can also (safely, I think) assume that a value gotten from the
innerHTML property can be put back in and give the same result.

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

This only thsts the ability to change, not to change correctly
It is probably enough, but you can do a test like this;

<div id="dummy">some <em class='dummyClass'>dummy</em> text</div>
<script type="text/javascript">
var elem = document.getElementById("dummy");
var oldIH = dummy.innerHTML;
dummy.innerHTML = "some <strong>other</strong> text";
var newIH = dummy.innerHTML;
dummy.innerHTML = oldIH:
var oldIH2 = dummy.innerHTML;
var IHworks = oldIH != newIH && oldIH == oldIH2;
</script>
If setting and reading innerHTML works, this is even non-destructive.


/L

 

[Jim Ley]

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.

I was relying on the fact it would be a normalised source, so by
putting in mixed case element names, and extra whitespace in the
elements I was relying that if innerHTML wasn't known, then it would
be the same (it would just be a new property on the DOM element) but
it if it was known it was normalised away.

Jim.

 

[Jim Ley]

You can also (safely, I think) assume that a value gotten from the
innerHTML property can be put back in and give the same result.

The same would be true of .chicken or a read only innerHTML that
resulted in no change afterwards. What we want to know is if our
content ended up on the page.

Jim.

 

[Lasse Reichstein Nielsen]

The same would be true of .chicken or a read only innerHTML that
resulted in no change afterwards. What we want to know is if our
content ended up on the page.

Ah, Doh. *slaps forehead*. Yes, simply testing that you can write
to it, is not sufficient.

You assume that the HTML is normalized when passed through innerHTML.
That is a fair assumption, and correct for the current browsers.

Another method could be to create an element with an id, and then check
whether it becomes part of the document with document.getElementById
(or fallbacks, e.g., document.all, as usual).


/L

 

[Dr John Stockton]

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

The same would be true of .chicken or a read only innerHTML that
resulted in no change afterwards. What we want to know is if our
content ended up on the page.

We want to know if the previous visible content (if any) is removed, if
new content appears, and if new content looks as expected; or if an
error message appears.

We, as authors, can never know, since writing for an unknown browser is
a one-way process. Only if we can run the same version of the same
browser and test it ourselves can we really know.

Our code can never know all of the above; it cannot detect a fatal
error, it cannot read the screen, and it cannot detect a systematic
delusion that the required property is spelt InnerHTML.


ISTM that

<div ID=X><FONT color=red>NO GOOD</font></div>
That should read "All seems well", in lime.

<script ... >
DynWrite('X', '<FONT color=lime>All seems well</font>')

should enable the user to tell whether things are at least to some
extent working.

 

[Lasse Reichstein Nielsen]

Just for my own curiosity, do you see any problems with the function
I wrote to check to see if it works?

I can see the same problem he pointed out in my attempt

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

Change "innerHTML" to "chicken" and it appears to work. That is, it only
tests whether there is a writeable property, not whether assigning to it
changes the document structure.
It would succeede in Netscape 4, if the getElementById had worked.

/L

 

[Dr John Stockton]

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

Just for my own curiosity, do you see any problems with the function I wrote to
check to see if it works?

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

One needs also to check that it fails correctly!

Consider
insertHTML('F', 'OK')
insertHTML('F', 'OK')
The second one will report failure. A script could well have an error-
message Div, writing 'OK' or a fault-report to it for each iteration.

I get no alert on once executing a version of the above with innerHTML
changed to innnerHTML, which implies that the pre-existence of innerHTML
must be tested.

One might read the existing innerHTML, add a character to it, write it,
and read back; that seems OK even if innerHTML is undefined.