Re: document.write and problems with how it overwrites existing code

RobG <rgqld@xxxxxxxxxxxx> wrote in news:cBchf.105$Hs.7415
@news.optus.net.au:

> Chris Lieb wrote:
> [...]
>> document.write can only modify the document while it is being loaded
>> initially. If you try to call it after the document has finished
>> rendering, the document is replaced.
>
> Your definition of 'modify' seems to exclude completely replace.
>
> It might be splitting hairs, but document.write can modify the document
> whenever it is called, but the effect of doing so after the document has
> finished loading is as you say - it replaces the content completely.
>
>
>> document.getElementById("currency").innerHTML = "Balance in the Piggy
>> Bank: $" + count;
>>
>> This will work in IE, but doesn't seem to in Gecko-based browsers
>> (Firefox and Mozilla).
>
> Did you test that? innerHTML is very widely supported and it works for
> me in both those browsers.


Here's the problem with the property 'innerHTML'. It does break in
earlier versions of NetNav and Mozilla, although these property-and-method
extensions of the "other major browser" developer may now be incorporated
in the script interpreter as fast as they are enunciated, and also
depending on whether any takes Microsoft seriously any longer in the
Javascript/JScript/ECMAscript war of script specifications.

I believe there are a class of script writers who is sticking to the
promulgations of the "Standards" organizations: ISO, W3C, ECMA. Or in
the case of the exceedingly humble and modest W3C, script writers are
sticking strictly to the "Recommendations" organizations (on the idea that
to assert "standards" for the organism that is the Internet is contrary to
the principle this organism is not be "chained" or "manacled" to things
like "standards").

At any rate, if 'innerHTML' is a specific extension of some browser
developer and not written in a universally respected specification, it
doesn't go in the code, with the warning that some day it just might break
in a future version when the interpretation of it is dropped.

Then there is the class of script writers who fill up their documents with
if-else code blocks that work with Browser #1, Browser #2, and Browser #3
when they won't operate with the common (dare we say standard?) code. (I
recommend this approach even though it invariably requires finding
getting-around-to-it time.)

I guess it just depends upon how adamant scripters want to be: follow
some org's standard, in which both the standard and the org as they are
now may not be around in 10 years, and assuming one actually believes
their script might hold up and be of use for that long....

.

Relevant Pages

  • Re: document.write and problems with how it overwrites existing code
    ... >>> for me in both those browsers. ... >> Here's the problem with the property 'innerHTML'. ... layers are properties/methods/objects that adhere to no standard. ... >> may now be incorporated in the script interpreter as fast as they are ...
    (comp.lang.javascript)
  • Re: preferred way of handling events
    ... browser developers must at least glance at the standards, ... bet that a standard approach will be more widely supported. ... script. ... for example - some browsers feature document.addEventListener, ...
    (comp.lang.javascript)
  • Re: How to access variables in an iframe?(Opera,JavaScript)
    ... Can I modify the code to meet ... opera's standard? ... var l=document.getElementById; ...
    (alt.html)
  • Re: Javascript form help
    ... which scripting language should be used to interpret the intrinsic event ... browsers default to interpreting intrinsic event attributes as JScript ... will guarantee otherwise avoidable script failure in some environments; ... interpreting HTML documents, ignoring the slash instead, but that does ...
    (comp.lang.javascript)
  • Re: Legacy code/browser compatibility
    ... a user of such an ancient browsers may see a syntax error ... either script supported or not. ... browsers, script will be supported. ... that doesn't support object literals ...
    (comp.lang.javascript)