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

Patient Guy wrote:

> Thomas 'PointedEars' Lahn <PointedEars@xxxxxx> wrote [...]
>> Patient Guy wrote:
>>> RobG <rgqld@xxxxxxxxxxxx> wrote [...]
>>>> 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,
>>
>> AFAIK major `innerHTML' issues were fixed in Mozilla/5.0 rv:0.9.1.
>> Of course Mozilla/4.x, which was very much broken, and early Mozilla
>> milestones, which were hardly usable beside being test cases, never
>> upported innerHTML nor did they support the W3C DOM. Mozilla/4.x
>> supports document.layers which no other UA does. Your point being?
>
> In the text that followed, the point was made.

It was not.

> It is that innerHTML and layers are properties/methods/objects that adhere
> to no standard.

True.

> It is true that they often emerge in the absence of a
> standard/specification/recommendation, and that the browser
> developer/manufacturer hopes that their idea catches on.

So? We are discussing _real-world_ implementations.

>>> although these property-and-method extensions of the "other major
>>> browser" developer
>>
>> Probably you are talking about the AOM/DOM of these browsers as that
>> is what it is. Not the language was extended, the AOM/DOM was.
>>
>>> may now be incorporated in the script interpreter as fast as they are
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> enunciated,
>>
>> It is not a language issue. Learn to understand the difference
>> between (interfacing) language and AOM/DOM.
>
> I don't claim it is a language issue.

Don't be ridiculous.

> In using innerHTML, the script writer risks (at a higher probability than
> something actually part of a standard) that the code will break in future
> versions of a browser which strictly adhere to standards.

No, only in using innerHTML _un-feature-tested_.

>>> and also depending on whether any takes Microsoft seriously any
>>> longer in the Javascript/JScript/ECMAscript war of script
>>> specifications.
>>
>> No, it is not. `innerHTML' is nowadays widely supported, not only by
>> Gecko-based and IE-based UAs. It is _not_ a Bad Thing to use it if it
>> is feature-tested before.
>
> see my comment above.

Which I cannot agree to. Browser scripting, or user agent scripting for
that matter, inevitably involves features that are not part of any
standard. There is no standard for `window' or `document', for example,
hence not even alert() and document.getElementById() etc. are per se
standards compliant. The host object referred to by `document' probably
implements parts of the Document or HTMLDocument interface, and that
interface provides a getElementById() method, but that is it. It is a Good
Thing to adhere to standards, but to make not adhering to them a no-no,
is ridiculous.

> Those who use non-standard code just because it works risk that the code
> will not work if even the browsers that feature the object/property/method
> decide not to later on.

You obviously have far too less professional experience in client-side
scripting to set the standards (in terms of minimum requirements) other
people's work should be based on.

>>> 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").
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> You have yet to understand what the ECMA and W3C are. FYI: They are
>> not the sole body bullying, and being completely independent of.
>> companies in the IT segment and other organizations that you present
>> it to be. Read the ECMA membership list, the W3C membership list and
>> the list of contributors to W3C specs.
>
> I wasn't making any attempt at all the describe the membership of these
> organizations or their structure. I was only commenting on one function
> they serve: to develop standards/specifications/recommendations which
> they hope are universally adopted in the interest of making software
> developers productive in making working code, and avoid a waste of time in
> writing browser-dependent code. To some degree, more or less, they
> achieve that goal.

True. However, you tried to belittle the status of standardization bodies
in general, the W3C and their specifications, by ignoring their members.

>> Standardization and recommendations helps to create interoperable
>> code. They help to keep things running in a way all can benefit. For
>> example, we would not be discussing here if there were not an RFC on
>> NNTP/UUCP.
>
> And I said something different from the purpose of what a standard or
> recommendation is?

You debated that Internet standards were viable in the first place:

(see above)
| [...] 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"

Not considering that this a appeal-to-motive logical fallacy (you cannot
know why the W3C decided to call their specifications "Recommendation" and
you cannot know why your "script writers" decided to follow them), Internet
standards _are_ _definitely_ viable or both of us would not be here now.

And not only <URL:http://www.w3.org/Consortium/> makes it clear that W3C
Recommendations should be considered Web standards. Since the Web is a
part of the Internet, that would make them Internet standards. You have
understood the difference between Web and Internet, have you not?

>>> 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.
>>
>> That is at best shortsighted reasoning . There is no specification
>> whatsoever on what window.open() really does and that goes for many
>> AOM/DOM features that at some point in history (before JavaScript 1.5)
>> were considered part of of the language and now are no longer but are
>> still widely supported through the AOM/DOM of user agents. There is
>> nothing wrong in using proprietary DOM features if the resulting code
>> is not written in a way that entirely depends on them.
>
> If you had read the entirety of my text

I have. Perhaps you should also have before submitting it.

> and actually not edited out

I have not edited out anything important to your argumentation. If I did,
it was because it was easy to miss the red thread in it, if there was any.
See below.

> (apparently for the sole purpose of being needlessly argumentative!),

If you you cannot face arguments against your arguments, this is the wrong
place for you.

> you will see that I make that very point that coding for browser-specific
> code is something a script writer is recommended in doing.

No, you made and make the point that what is not standardized should
therefore not be used at all. Which is wrong, especially in terms of
Web browser scripting.

> I insert the text here that I wrote in the post you responded to, and
> which you either did not read or did not understand:
>
> 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.)

So? You point out that your very argument contains a contradiction.
But perhaps you were not argumenting at all.

> [...]
>> And in 10 years from now, it is highly unlikely that any current script
>> code will still work, let alone the Internet and Web being what it is
>> now.
>
> "...and assuming one actually believes their script might hold up
> and be of use for that long..."

Again a contradiction in your argument. You argue for standards because
they are long-living (they /are/ longer living than proprietary approaches,
that's for sure), but you argue also that any script may not be usable in
the future. If you want to argue for or against something, you better
decide what are you arguing for or against.


PointedEars
.

Relevant Pages

  • Re: Development with IE 7 for non-Windows users.
    ... standards that most other browsers accept, I rely only on the standards. ... It is only the rendering engine itself that is to blame. ... Sometimes script can be very useful. ... Obviously, if a users browser ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: Script error on Google Homepage
    ... >> should behave when innerHTML has been changed. ... A proper innerHTML specification would explain exactly what the browser ... to do its job -- conforming to those same standards. ... are you looking for more conformance or compliance in your ...
    (microsoft.public.scripting.jscript)
  • Re: missing ) after argument list
    ... >> and there is proof that at least one script engine, the JavaScript ... Give one browser, just one that produces a syntax error ... Are you arguing that standards are irrelevant and that we should just ...
    (comp.lang.javascript)
  • Re: A suggestion for a new Web standard (Discussion)
    ... browser, and then compiled into byte code. ... is smaller than the original script. ... No bytecode, this is Javascript, not Java. ... standards doesn't necessarily mean that that's ALL you can do. ...
    (comp.lang.javascript)
  • Re: ajax & php & javascript
    ... do with inserting the script via innerHTML and the script blocks don't get processed when doing that. ... If you want to execute script blocks, then you will have to use a different method of inserting it in the page to get the browser - any browser - to execute the script. ... The only browser I recall that executed script's inserted via innerHTML was NS6. ...
    (comp.lang.javascript)