R
Richard Cornford
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.
As they should, but validators do not always apply the same criteria to
deciding which type a document is as browsers apply.
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.
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.
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.
IE does not support XHTML at all, it is an HTML web browser and
Microsoft have never claimed anything different.
<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.