IE no doing "onload" function?

[fred.haab]

Not having server side scripting, I've been doing this for "last
modified" tags on my pages:

<div class="modified">
<script type="Text/JavaScript">
<!--
document.write("This page was last modified: " +
document.lastModified);
-->
</script>
</div>

It suffices, but supposedly it's better to separate content and the
code.

So in a separate js file I did this:

window.onload = last_modified;

function last_modifed()
{
var obj = document.getElementById("modified");
obj.innerHTML = "This page was last modified: " +
document.lastModified;
}

With this html in my documents:

<div id="modified" class="modified">&nbsp;</div>

It does't work in my IE (6), but works fine in Firefox. Any
suggestions?

 

[VK]

So in a separate js file I did this:

window.onload = last_modified;

function last_modifed()
{
var obj = document.getElementById("modified");
obj.innerHTML = "This page was last modified: " +
document.lastModified;
}

With this html in my documents:

<div id="modified" class="modified">&nbsp;</div>

It does't work in my IE (6), but works fine in Firefox. Any
suggestions?

Put
window.onload = last_modified;

after the function declaration (at the end of your script).

 

[Richard Cornford]

(e-mail address removed) wrote:

Put
window.onload = last_modified;

after the function declaration (at the end of your
script).

It is not even a couple of days since were beaten into accepting that
variable declarations are acted upon during variable instantiation,
prior to the execution of any actual code for the execution context. You
even claimed to have read the specification. Yet you didn't see, or
didn't understand, that the same is true of function declarations.

The location of an assignment of a reference to a declared global
function in the global execution context does not matter because the
function will have been created prior to the execution of any actual
code.

If you are not capable of actually comprehending javascript yourself you
really should not bother other people with the nonsense that you mistake
for an understanding of javascript.

Richard.

 

[VK]

function last_modifed()
but
window.onload = last_modified;

you have a typo in modified.

 

[VK]

It is not even a couple of days since were beaten into accepting that
variable declarations are acted upon during variable instantiation,
prior to the execution of any actual code for the execution context. You
even claimed to have read the specification. Yet you didn't see, or
didn't understand, that the same is true of function declarations.

I found the actual error - see another post. For the mater of variable
instantiation it is just not my cup of tea I'm affraid. I mean of
course I understood the trick (so stupid I'm not but I simply don't
like it. So I will continue to declare all used variable explicetly in
my code: you can call it instead then "list all used variable in
advance". And for functions I will put references and calls only after
function declarations. Maybe it doesn't have any sense - but I just
used to do so and it is useful for the consistency with other
languages. Anyone is welcome though to act otherwise.

 

[Richard Cornford]

I found the actual error - see another post.

Does the error you pointed out actually explain the symptoms described?
Will the code with that error work in Firefox but not work in IE6? If
the symptoms are real then the code posted cannot be producing them, so
you may have just pointed out a typo in the posted code.

For the mater
of variable instantiation it is just not my cup of tea I'm
affraid. I mean of course I understood the trick (so stupid
I'm not but I simply don't like it. So I will continue to
declare all used variable explicetly in my code: ...

<snip>

You just don't get it, do you? In response to the posted question you
have proposed an action that you should have known would make no
practical difference at all. It doesn't matter that 'best practice' may
be to declare variables and functions before other code. You were not
recommending those changes as a gesture towards beast practice, you were
implying that it might make a difference that might resolve the issue.
Implying that you were not aware that it should not be expected to make
any difference at all.

All your response to my comments represents is yet another lame attempt
to excuse your evident incompetence.

Richard.

 

[fred.haab]

As Richard surmised, it was a typo in cutting and pasting. Correctly
named, it works in Firefox, but not IE.

 

[fred.haab]

Yes, I would like to follow "best practices" so that my web pages
degrade as gracefully as possible, so given what you wrote, do you have
any suggestions about why this may not work in IE?

The first example, with the inline script, works. The second does not
(in IE).

Thanks,
Fred

 

[fred.haab]

I've discovered that IE simply doesn't like my .js file at all, even
with only what you see in my first post. If I remove the <script> tag
that loads the .js file, IE will at least display (but no script). If
I leave the script tag in, IE won't display ANYTHING, not even static
content right in the HTML file.

Maybe the tag is in the wrong place? I have it in <head> element.

 

[Richard Cornford]

I've discovered that IE simply doesn't like my .js file at all,
even with only what you see in my first post. If I remove the
<script> tag that loads the .js file, IE will at least display
(but no script). If I leave the script tag in, IE won't display
ANYTHING, not even static content right in the HTML file.

Maybe the tag is in the wrong place? I have it in <head> element.

A SCRIPT element is allowed to be the direct child of a HEAD element in
HTML documents.

Maybe your SCRIPT element is wrong itself. If you attempted to apply the
illusion of XHTML to an HTML document with a SCRIPT element such as:-

<script src="removteFile.js" type="text/javascript" />

- some browsers may be capable of error correcting that back into an
HTML script element, while others (and certainly IE) would not be able
to cope with that level of error correction and so see that as only the
opening SCRIPT tag, making everything that followed it into the contents
of the script elements. In the second case the result likely would be an
empty browser window.

Richard.

 

[VK]

As Richard surmised, it was a typo in cutting and pasting. Correctly
named, it works in Firefox, but not IE.

Then (as he also surmised) there is something fishy in the way you are
using <script> element. I have no further ideas until I can see the
page itself (can be brought to the minimum case to demonstrate the
problem).

 

[Richard Cornford]

Yes, I would like to follow "best practices" so that my
web pages degrade as gracefully as possible, ...

Writing scripts so that clean/gracefully degradation is facilitated is a
'best practice' for Internet scripts, it is not a consequence of
following other 'best practices'. The imposition of formal structure in
the source code will make no difference to how it executes, it is a
'best practice' because it improves the readability and maintenance of
that code. Clean/gracefully degradation is (or may be) a consequence of
considerate script design.

Richard.

 

[Richard Cornford]

Then (as he also surmised) there is something fishy in the
way you are using <script> element. ...

If you really did surmise that why didn't you mention it in your
previous posts in this thread?

This is just another of your lame excuses. If you don't want to make
yourself look a fool in public (so not have to issue a series of
excuses) you should either learn javascript or stick to only attempting
to answer the really trivial questions, because you sometimes manage to
answer those (more or less) correctly.

Richard.

 

[VK]

This is just another of your lame excuses. If you don't want to make
yourself look a fool in public (so not have to issue a series of
excuses) you should either learn javascript or stick to only attempting
to answer the really trivial questions, because you sometimes manage to
answer those (more or less) correctly.

Richard, maybe it is enough of enjoying of your Identifier issue
victory? I was theoretically and practically wrong. You indeed have
read ECMA Books throughout to the end and back to the beginning.
Probably no one better than you in this group can explain of how
something /should/ work by specs. In some cases (like the one with
Identifier declarations) you can point on some not so obvious effects
of specs on specs-compliant engines. Yet /outside/ of ECMA Books
your're doing sometimes mistakes as embarassing as I do /within/ them.
But to you in such case it is always "proprietary wronly implemented
non-widely supported behavior I don't care about".

The IXMLHTTPRequest behavior I posted uses N amount of Global spaces on
one page (one per bound element). I was waiting your reaction to move
on the Gecko equivalent. The only reaction I got was "it doesn't prove
anything".
"I don't see it, I don't hear it, here is what's written"...

 

[Richard Cornford]

Richard, maybe it is enough of enjoying of your Identifier
issue victory? I was theoretically and practically wrong.

Yet again.

You indeed have read ECMA Books throughout to the end and
back to the beginning. Probably no one better than you in
this group can explain of how something /should/ work by
specs. In some cases (like the one with Identifier
declarations) you can point on some not so obvious effects
of specs on specs-compliant engines. Yet /outside/ of ECMA
Books your're doing sometimes mistakes as embarassing as I
do /within/ them. But to you in such case it is always
"proprietary wronly implemented non-widely supported behavior
I don't care about".

I realise that much of what I wrote goes right over your head. Your
perception is in error, but that is hardly surprising given your record.

While you are winging about my having a good theoretical understanding
of how javascript should work you should bare in mind that while you
struggle to accommodate more than a couple of browser (and so resort to
deriding all the browsers you cannot cope with) I have a demonstrated
ability to design and create scripts that are truly cross-browser.

The bottom line is that a good theoretical understanding of the language
is invaluable in the practical application of the language. That is why
some of the more recent additions to the regular contributors to this
group have, in a couple of years, understood more that you have in the
10 odd years you claim to have been scripting browsers. They have seen
that learning the theory aids the practice.

The IXMLHTTPRequest behavior I posted uses N amount of Global
spaces on one page (one per bound element). I was waiting your
reaction to move on the Gecko equivalent. The only reaction I
got was "it doesn't prove anything".
"I don't see it, I don't hear it, here is what's written"...

It is typical of you that when you have made yourself look a fool you
then go off on some irrelevant tangent in an attempt to look less
stupid. It doesn't really work as everyone can see that you are being
irrelevant and just perceive your actions as a manifestation of
non-joined-up thinking (or a symptom of insanity in extreme cases).

Don't you think random readers of this thread deserve some sort of
reference to the thread you are referring to so they have some context
for your comment here?

But I did not say "doesn't prove anything" in response to your "N amount
of Global spaces" nonsense. I said that you had failed to demonstrate
any substance to your other whittering in that thread about the window
and the page script's global objects being distinct in IE browsers. The
two have no relationship.

I did respond to your "N amount of Global spaces" nonsense with:-

<quote cite="VK wrote:
....

I promised to show how to use parallel Global spaces to
implement private/protected members a while ago.

<snip>

Nobody else cares. You are the only person perverse enough to attempt
to reproduce a capability that is inherit in the language by
specification, and do so in a way that is dependent upon the host
environment, differently dependent in different host environments
(requiring separate implementations for each environment), smeared in
little chunks throughout the document and several subsidiary files,
and only possible in precisely two host environments. Another example
of your preferring to things in the worst possible way available.
</quote>

That is all the response you proposal deserves: it is pointlessly
expensive (in every sense of the word), bloated and perverse attempt to
achieve, in no more than two environments, what can be trivially
achieved in every ECMAScript environment. It is no more than an
opportunity to do something badly when there are already well known ways
of doing much better. A worthless 'contribution' to the world of browser
scripting.

Given that you have a strong tendency to prefer the worst possible
approach to almost anything, I can see how that idea would appeal to
you. Especially since the better alternatives do require a real
understanding of javascript. Something that you have never been able to
achieve yourself.

The bottom line is that if you want to interest anyone else in that idea
you should go an find yourself someone as ignorant and foolish as you
are, there is no point in bothering anyone here with your noise.

Richard.

 

[Randy Webb]

(e-mail address removed) said the following on 5/25/2006 9:50 PM:

Yes, I would like to follow "best practices"

Then please quote what you are replying to.

If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the

so that my web pages degrade as gracefully as possible, so given
what you wrote, do you have any suggestions about why this may
not work in IE?

VK lives in lala land and needs a 20 year vacation to some remote desert
island where computers don't exist.

Degrading has nothing to do, as Richard already said, with how code is
written.

As for the Best Practice of how and where you define variables? That is
purely 100% personal preference.

The first example, with the inline script, works. The second does not
(in IE).

Does your external .js file have the script tags still in them? Or HTML
comment tags <!-- //-->? Oops, those are, pedantically, "SGML Comments"
(I have to include that so that the pedantic people don't jump on that
one). The only thing that can be in external files is script code and
script comments.

 

[Rich]

On 25 May 2006 08:23:44 -0700, (e-mail address removed) wrote...

Not having server side scripting, I've been doing this for "last
modified" tags on my pages:

<div class="modified">
<script type="Text/JavaScript">
<!--
document.write("This page was last modified: " +
document.lastModified);
-->
</script>
</div>

It suffices, but supposedly it's better to separate content and the
code.

So in a separate js file I did this:

window.onload = last_modified;

function last_modifed()
{
var obj = document.getElementById("modified");
obj.innerHTML = "This page was last modified: " +
document.lastModified;
}

With this html in my documents:

<div id="modified" class="modified">&nbsp;</div>

It does't work in my IE (6), but works fine in Firefox. Any
suggestions?

I've had descent luck using the "onload()" event in the <BODY> tag. I got this
to work in IE v6


<head>
<script type="Text/JavaScript">
<!--
function last_modifed()
{
var obj = document.getElementById("modified");
obj.innerHTML = "This page was last modified: " +
document.lastModified;
}
//-->
</script>
</head>

<body onload="last_modifed()">
<div id="modified" class="modified">&nbsp;</div>
</body>


Rich

 

[fred.haab]

Maybe your SCRIPT element is wrong itself. If you attempted to apply the
illusion of XHTML to an HTML document with a SCRIPT element such as:-

Now that I've thought about it for a little while, I don't think so (I
don't think it's wrong for an xhtml element to be closed that way...
and neither do the validation tools I've been using, which do validate
xhtml differently than html). I don't know why you would call my xhtml
file only an "illusion" of being xhtml, either... it's got all the
appropriate tags for xhtml.

<script src="removteFile.js" type="text/javascript" />

- some browsers may be capable of error correcting that back into an
HTML script element, while others (and certainly IE) would not be able
to cope with that level of error correction and so see that as only the
opening SCRIPT tag, making everything that followed it into the contents
of the script elements. In the second case the result likely would be an
empty browser window.

Richard.

Now, as for the javascript problem, it seems you are correct - IE
doesn't understand the the closing / at the end of the <script> tag.
It does work when I put </script> instead... but I would hardly call
the way I did it an error. Again, neither do the validation tools.

That to me says that it's another one of the many browser problems out
there because IE doesn't understand a perfectly valid closing tag for
an xhtml document. The page validates fine using the validation tools
available on Firefox - no errors, no warnings, and it does recognize my
document as xhtml - not only because it says so, but because it gives
me xhtml specific warnings (for example, when I don't close a <br> like
<br />), which it doesn't do when it's validating html.

The bare minimum page, with some sample text before and after the
last_modified tag, is available here:

http://frhaab.home.comcast.net/test/template.html

Which you can plug into validator.w3.org, and receive the following:

"The document located at
<http://frhaab.home.comcast.net/test/template.html> was checked and
found to be valid XHTML 1.0 Strict."

So, while I have a solution, to me it's another IE bug (not that other
browsers don't have them), unless I'm missing something.

My intention isn't also to just bash IE, because it's done things the
way I thought they should work where Firefox hasn't, but here we have a
perfectly valid document that IE won't display.

 

[Thomas 'PointedEars' Lahn]

Now that I've thought about it for a little while, I don't think so (I
don't think it's wrong for an xhtml element to be closed that way...

And it is not. However, declaring XHTML unfortunately does not make it be
parsed as XHTML, i.e. by an XML parser to recognize the XML NETC SHORTTAG
syntax. Usually that requires that the resource is served with an XML
media type, for XHTML preferably application/xhtml+xml.

and neither do the validation tools I've been using, [...]

Validators cannot (and IMHO, should not) re-implement the parser selection
mechanism of currently widely distributed Web user agents. (Instead, those
user agents should parse the prolog of a resource before they select the
parser to be used for the rest, as recommended by RFC2854.)

<script src="removteFile.js" type="text/javascript" />

- some browsers may be capable of error correcting that back into an
HTML script element, while others (and certainly IE) would not be able
to cope with that level of error correction and so see that as only the
opening SCRIPT tag, making everything that followed it into the contents
of the script elements. In the second case the result likely would be an
empty browser window.
[...]

Now, as for the javascript problem, it seems you are correct - IE
doesn't understand the the closing / at the end of the <script> tag.
It does work when I put </script> instead... but I would hardly call
the way I did it an error. Again, neither do the validation tools.

That to me says that it's another one of the many browser problems out
there because IE doesn't understand a perfectly valid closing tag for
an xhtml document.

The simple reason is that IE does not support XHTML at all, which can be
easily proven by serving it with the recommended (and, IMHO, only
reasonable) media type application/xhtml+xml.

When IE or another UA is served an XHTML resource as text/html, the tag
soup parser used for HTML is also used for XHTML. It is a tag soup parser,
because if it was an HTML parser it would follow SGML rules. The SGML
declaration of HTML enables the SHORTTAG feature, that is, <.../> strictly
equals <...>&gt; in HTML. A tagsoup parser does not implement this
feature, but wrongfully error-corrects it to <...>. But if XHTML's
<script .../> is error-corrected to HTML's <script ...>, the close tag that
was allowed to be omitted when using the XML NETC SHORTTAG syntax is then
no longer present. Therefore, everything that follows must be regarded by
that parser as the content of the `script' element. With the next start
tag triggering a script syntax error, as `<' is an operator in the script
languages that apply, and would require a preceding operand that is missing
then.


HTH

PointedEars

 

[fred.haab]

Validators cannot (and IMHO, should not) re-implement the parser selection
mechanism of currently widely distributed Web user agents.

Well, being anal retentive, actually, they should implement the correct
parser regardless of what's widely available, otherwise standards
become meaningless. Just my $0.02.

In other words, I'd rather my document not render correctly (but good
enough) in one or two UAs now if, in the future, they complied and
rendered them correctly... just so long as it wasn't too bad, at least.