By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,728 Members | 2,488 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,728 IT Pros & Developers. It's quick & easy.

IE no doing "onload" function?

P: n/a
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?

May 25 '06 #1
Share this Question
Share on Google+
28 Replies


P: n/a
VK

fr*******@gmail.com wrote:
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).

May 25 '06 #2

P: n/a
VK wrote:
fr*******@gmail.com wrote:

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


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.
May 25 '06 #3

P: n/a
VK
function last_modifed()
but
window.onload = last_modified;

you have a typo in modified.

May 25 '06 #4

P: n/a
VK

Richard Cornford wrote:
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.

May 25 '06 #5

P: n/a
VK wrote:
Richard Cornford wrote:
fr*******@gmail.com wrote:
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).
<snip> 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.


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.
May 25 '06 #6

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

May 26 '06 #7

P: n/a
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

May 26 '06 #8

P: n/a
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.

May 26 '06 #9

P: n/a
fr*******@gmail.com wrote:
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.
May 26 '06 #10

P: n/a
VK
fr*******@gmail.com wrote:
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).

May 26 '06 #11

P: n/a
fr*******@gmail.com wrote:
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.
May 26 '06 #12

P: n/a
VK wrote:
fr*******@gmail.com wrote:
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. ...


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.
May 26 '06 #13

P: n/a
VK

Richard Cornford wrote:
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"...

May 26 '06 #14

P: n/a
VK wrote:
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="news:e4*******************@news.demon.co.uk" >
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.
May 26 '06 #15

P: n/a
fr*******@gmail.com 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
article headers. <URL: http://www.safalra.com/special/googlegroupsreply/ >
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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 26 '06 #16

P: n/a
Richard Cornford wrote:
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.

May 26 '06 #17

P: n/a
fr*******@gmail.com wrote:
Richard Cornford wrote:
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 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.

See also: <URL:http://hixie.ch/advocacy/xhtml>
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
--
http://members.ud.com/download/gold/
http://folding.stanford.edu/
http://alien.de/seti/
http://setiathome.ssl.berkeley.edu/
May 27 '06 #18

P: n/a

Thomas 'PointedEars' Lahn wrote:
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.

May 27 '06 #19

P: n/a
fr*******@gmail.com wrote:
Richard Cornford wrote:
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...


It is not wrong for an XHTML tag to end like that, it is a standard XML
shorthand for an element that has no content. The problem is that your
document is not really XHTML, at lest the browsers don't think it is and
there opinion of the document determines how they handle it.
and neither do the validation tools I've been using, which
do validate xhtml differently than html).
As they should, but validators do not always apply the same criteria to
deciding which type a document is as browsers apply.
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.
I call it the illusion of XHTML because it looks like XHTML to one
observer and looks like (error filled, so tag soup) HTML to another (the
browser). Illusion seems a reasonable term to apply to a misleading
appearance.

Because our subject here is javascript, so mostly the scripting of the
object model provided by web browsers, we see the manifestation of the
difference between an HTML document and an XHTML document in the DOM
created by the browser to be scripted.

Presented with (what it thinks is) an HTML document a browser will
create an HTML DOM to be scripted. An HTML DOM uses case insensitive tag
names, is unaware of namespaces, prefers the direct assignment to
element properties over the setAttribute method and provides numerous
traditional features and shortcuts. While a browser presented with what
it perceives as an XHTML document (if it supports XHTML at all) will
create an XHTML DOM instead. The XHTML DOM uses case sensitive tag
names, has in interest in namespaces, prefers setAttribute(NS) over
direct assignment to Element properties and tends not to support
shortcuts, features and convenience properties that are not formally
specified. They also do not implement some features that do not fit well
with XML parsing, such as not supporting the - document.write(ln) -
method.

Generally, very few non-trivial browser scripts are capable of
successfully operating with both types of DOM (and writing single
scripts that will introduces an entire extra level of testing and
branching on top of that normally required for cross-browser scripting).

This makes it very important for script authors to be very clear about
what type of DOM is going to be created by the browser, and so very
important to understand the browser's attitude towards the documents it
receives. The browser sees through the illusion of XHTML and so we must
also see through that illusion in order not to be fooling ourselves into
scripting the wrong type of DOM.

Web browsers almost entirely make their decision as to which type of
document they are receiving based upon the HTTP content-type header.
Which, from the point of view of an HTTP user agent, is the only
reasonable criteria. If a document is served to them with a content-type
of (or including) text/html they assume that the document is HTML and
treat it as such (passing it into their HTML parser and crating an HTML
DOM). Even if the mark-up in the document resembles (or even validates
as) XHTML the browser will still treat it as HTML, and so apply its tag
soup error correction rules to fix all the XML oddities it encounters in
what it is assuming is HTML mark-up (or at least as many as it can).

If a document is served with an XHTML content type (usually the
recommended application/xhtml+xml), if it can, the browser will
interpret the document as XHTML and create an XHTML DOM to be scripted.

Loading your page into Mozilla (which supports XHTML and so can create
an XHTML DOM if it sees the document as XHTML) and opening the "page
info" dialog shows your content type header as:-

content-type text/html; charset=iso-8859-1

- and lists the type as "text/html". Showing that even a browser that
can understand XHTML is seeing the document as HTML. This is why your
XHTML is an illusion; you see it that way but you have not convinced the
browsers.

Of course IE doesn't understand XHTML at all so it will never interpret
a document as XHTML, and cannot build an XHTML DOM at all. IE tends to
offer the user the opportunity to save documents served as
application/xhtml+xml to disc rather than even attempt to display them.
<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.


Without being able to see your source code (and in this case without
being able to access it online to verify the HTTP headers) that was a
guess on my part. A possibility that could fully explain the symptoms
described. There was nothing in your original post to suggest an attempt
to use XHTML at all.
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.
The problem with the vaidators is that they recognise what is called
"Appendix C XHTML 1.0" as XHTML. Appendix C describes a set of rules to
facilitate serving XHTML style mark-up to web browsers that do not
understand XHTML. It includes the proposal that such documents may be
served as text/html, as they must if the non-XHTML browsers like IE are
to render such documents at all.

The problem is that because it allows (superficially) XHTML documents to
be served as text/html, appendix C acts to convince authors that they
are working with XHTML when the browser at the receiving end still
thinks it is receiving HTML. Appendix C is effectively a set of rules
for the creation of formally malformed HTML, where the malformations are
within the HTML browsers ability to error correct and the whole result
is well-formed XML and XHTML mark-up (so can be validated as XHTML).
Confusion and misconceptions follow from this situation, but as script
authors we cannot afford to be taken in. We must see through all this
and take the position that the real type of a document is the type that
the browser thinks it is, because that will then the type of DOM we will
be scripting.
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.
IE does not support XHTML at all, it is an HTML web browser and
Microsoft have never claimed anything different.

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

<snip>

I hope that you have now seen why I speak of the illusion of XHTML, and
that your were missing something; that the document is an HTML document
in reality and so IE's interpretation of the SCRIPT tag is not
unreasonable.

Richard.
May 27 '06 #20

P: n/a
fr*******@gmail.com wrote:
Thomas 'PointedEars' Lahn wrote:
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.


But they do; take the W3C Validator as an example. In absence of the
correct/recommended media type declaration such as here, the parser to be
used to parse (and validate) the markup should be determined by evaluating
the prolog of the document, particularly the DOCTYPE declaration.
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.


You are confusing the issue. It is you (serving XHTML as text/html) and
the UAs (parsing XHTML as wrongfully error-corrected HTML if served as
text/html) that have a problem, not the validators (that I know of).
PointedEars
--
The English government is much of a German poodle as
other governments. The Germans infiltrated them all.
-- "The only real Barbara Schwarz", dsw.scientology,
<16**************************@posting.google.com >)
May 27 '06 #21

P: n/a
Thomas 'PointedEars' Lahn wrote:
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 <...>. [...]


This can be misunderstood, for it does not apply to /any/ other UA. There
are UAs out there that (at least partially) implement SHORTTAG correctly,
and therefore (at least to a point) cannot be considered to use a tag soup
parser. Which is one reason why serving XHTML as text/html is considered
harmful.

See also: [de] <URL:http://dodabo.de/html+css/tests/shorttag.html>
PointedEars
--
I hear, and I forget; I see, and I remember; I do, and I understand.
-- Chinese proverb
May 27 '06 #22

P: n/a
VK

fr*******@gmail.com wrote:
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.


So that was the issue? You used
<script type="text/javascript src="myScript.js" />
syntax and it failed to work?

In this case it looks like a trolling OP (sorry to say) because:

1) This vital part of the problem was left for guessing.
2) It was stated that <q>It does't work in my IE (6), but works fine in
Firefox</q> which is a clear provocation: it doesn'r work in /neither/
browser if served as text/html
It will work on XHTML-aware browsers if served with proper content type
like application/xhtml+xml. But in such case you would also mention a
strange behavior on IE (Save As prompt instead of page display). And if
you do some UA / Accept header sniffing server-side and set
Content-Type accordingly, you /have/ to mention it clearly in OP.

So the right question (not a call for guessing) would be like:
<script type="text/javascript src="myScript.js" /> wich is proper XHTML
syntax works fine for Firefox if page is served as
application/xhtml+xml
At the same time it doesn't work (ignored) if the page is served as
text/html. It doesn't work in neither case on IE. What is the problem?

In this case no one would have to guess and restore your situation and
you would be pointed right away to one of discussions like
<http://groups.google.com/group/comp.infosystems.www.authoring.html/browse_frm/thread/6ff8329925aae8a6/cc7ca3f2132c0416>
with test results like
<http://groups.google.com/group/comp.infosystems.www.authoring.html/tree/browse_frm/thread/6ff8329925aae8a6/f3d25d58d6adcfea#doc_32017f7edac4940d>

May 27 '06 #23

P: n/a

VK wrote:
So that was the issue? You used
<script type="text/javascript src="myScript.js" />
syntax and it failed to work?

In this case it looks like a trolling OP (sorry to say) because:


Well, if my xhtml document is only an illusion, then so is your guess.
I had no idea something that I thought was supposed to parse an xml
style couldn't handle a proper closing tag. The book I'm referencing
on the subject, "Web Desgin in a Nutshell", encourages use of xhtml 1.0
strict or xhtml 1.1, but I must have missed the part where she said
"but IE doesn't parse xhtml correctly." Now I know.

May 27 '06 #24

P: n/a
fr*******@gmail.com wrote:
I had no idea something that I thought was supposed to parse an xml
style couldn't handle a proper closing tag. The book I'm referencing
on the subject, "Web Desgin in a Nutshell", encourages use of xhtml 1.0
strict or xhtml 1.1,
See <URL:http://www.w3.org/TR/xhtml-media-types/#summary>, then my .sig :)
but I must have missed the part where she said
"but IE doesn't parse xhtml correctly." Now I know.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That is an understatement. If it was only incorrect parsing, one could
work around that. IE simply does not support XHTML (let alone HTML), and
that is not going to change for the foreseeable future. Because IE 7 that
was announced to /finally/ fix the numerous flaws IE 6 had, still does not
support XHTML (to my knowledge -- prove me wrong![1]), while all other
widely distributed browsers do more or less (with Geckos being the foremost
UAs in this field).
PointedEars
___________
[1] <URL:http://pointedears.de/scripts/test/dom.xhtml?strict>
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
May 27 '06 #25

P: n/a
VK wrote:
So that was the issue? You used
<script type="text/javascript src="myScript.js" />
syntax and it failed to work?

In this case it looks like a trolling OP (sorry to say)
because:

1) This vital part of the problem was left for guessing.
You are accusing someone of trolling because they did not provide
complete context information in their original post? That attitude would
designate 80% plus of the OPs in this group trolls.

Are you sure you are not over reacting to having embarrassed yourself so
spectacularly, yet again?
2) It was stated that <q>It does't work in my IE (6), but
works fine in Firefox</q> which is a clear provocation: it
doesn'r work in /neither/ browser if served as text/html
Not true. Mozilla's tag-soup error correction has been modified to
accommodate this. That change will probably serve to make the illusion
of XHTML in text/html documents even harder to spot for page authors but
it does go along with the 'what you accept' side of 'be strict in what
you send and tolerant in what your accept'. XHTML has made that error
more prevalent in HTML documents so it is not surprising when
error-correction is updated to accommodate it.

<snip> So the right question (not a call for guessing) would
be like:
<script type="text/javascript src="myScript.js" /> wich
is proper XHTML syntax works fine for Firefox if page is
served as application/xhtml+xml
At the same time it doesn't work (ignored) if the page is
served as text/html. It doesn't work in neither case on
IE. What is the problem?
The FAQ already provides better advice on the effective asking of
questions that anything you could suggest. And of course the pages being
served as application/xhtml+xml is an irrelevance in this situation
(they never were being served as such) and so should not be erroneously
stated.
In this case no one would have to guess ...


Whether or not it should be necessary to guess, your mistake here (and
in the many similar situations) was to guess without reading or
understanding the symptoms described. If you looked at the code and the
infuriation provided as observed that the code could not produce the
symptoms described then an appropriate response would be to point that
out, and imply that more information would be necessary.

Instead you elected to make a spurious, 'mystical incantation'
suggestion that neither addressed the issue nor explained the symptoms.
Not understanding javascript at all you are doomed to do that, but there
is no point calling the OP names because you cannot practice joined-up
thinking.

Richard.
May 27 '06 #26

P: n/a
Richard Cornford wrote:
<snip>
... . If you looked at the code and the infuriation
provided as observed that the code could not produce
the symptoms described ...

<snip>

That should have read "... the code and the information provided and
observed ...".

Richard.
May 27 '06 #27

P: n/a
VK

fr*******@gmail.com wrote:
Well, if my xhtml document is only an illusion, then so is your guess.
I had no idea something that I thought was supposed to parse an xml
style couldn't handle a proper closing tag. The book I'm referencing
on the subject, "Web Desgin in a Nutshell", encourages use of xhtml 1.0
strict or xhtml 1.1, but I must have missed the part where she said
"but IE doesn't parse xhtml correctly." Now I know.


You are still missing another very important part: even if UA supports
XHTML, it doesn't treat an XHTML page (however perfectly valid it would
be) as XHTML /unless/ such page is served with the corresponding
Content-Type application/xhtml+xml.
If it's served with Content-Type text/html, it is treated as HTML with
extra trash to ignore in some tags.
Note: Content-Type has to be set by server, not in HTTP-EQUIV meta on
the page itself, because server header has higher priority.

HTTP protocol doesn't give a damn about what do you /think/ the
document is. So the regular "powerful spells" like

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

have the effect (an absence of such more precisely) as

<!-- IT IS TRULLY DEEPLY VALID XHTML PAGE
ANY UA SUPPORTING XHTML IS REQUIRED
TO TREAT THIS PAGE WITH FULL RESPECT AS XHTML.
ALL VIOLATIONS WILL BE PROSECUTED BY W3C POLICE -->
<html>
// the rest of your page

Both set of "spells" would have no effect without proper Content-Type.
The fact that this is not clearly stated in your book suggests to
switch on some other book.

May 27 '06 #28

P: n/a

VK wrote:
You are still missing another very important part: even if UA supports
XHTML, it doesn't treat an XHTML page (however perfectly valid it would
be) as XHTML /unless/ such page is served with the corresponding
Content-Type application/xhtml+xml.
If it's served with Content-Type text/html, it is treated as HTML with
extra trash to ignore in some tags.
Note: Content-Type has to be set by server, not in HTTP-EQUIV meta on
the page itself, because server header has higher priority.


Yes, that is what I was missing, and that explains a lot.

May 27 '06 #29

This discussion thread is closed

Replies have been disabled for this discussion.