Mike said:
Richard Cornford said:
I've heared others say that, but I don't understand it because it
does work in Mozilla (I've provided a little test case at the end of
this post).
The illusion that it works is brought about by writhing to XHTML 1.0
_Appendix_C_ and serving the pages as text/html. But Appendix C defines
a strategy for creating XHTML files that can be interpreted as (or, more
realistically, error-corrected into) HTML, and content type herders of
text/html tell the browser that what it is getting is HTML, so it
interprets it as such. From the point of view of a script the type of
document is decided by the browser's interpretation of the document, not
its author of the document.
So upon receiving a document that asserts that it is HTML (with its
headers) and can be interpreted as HTML (although littered with apparent
mistakes and syntax errors that need fixing) the browser, not
unreasonably, treats it as an HTML document and builds an HTML DOM from
it.
I can't find it in the XHTML 1.0 spec. Is it in the 1.1
spec?
From the scripting point of view the pertinent specification is the W3C
HTML DOM specification. It defines numerous interfaces that may be
implemented in hypertext document object models and notes the ways in
which XHTML implementations should differ from HTML implementations
(mostly concerning the handling of namespaces and case sensitivity).
However, the Mozilla XHTML DOM implementation does not include all of
the interfaces defined in the W3C HTML DOM specification. Specifically
they have decided to omit the HTMLDocument interface, and that means
there are no document level "convenience" properties (forms, plugins,
etc) and no write or writeln methods. Opera's XHTML DOM implementation
does include the HTMLDocument interface on the document object, it just
doesn't provide any means of running an imported or inline script (event
handlers only).
So it is not a matter that XHTML DOMs are not allowed a write method, it
is just that the most common scriptable XHTML DOM implementation does
not support it (a purely practical consideration).
Is that why it works in my test case?
If you send the document with text/html headers the only person who
thinks it is XHTML is its author, every other part of the system thinks
it is (erroneous) HTML.
Its confusing to me that
a markup language spec would have anything to say
about objects exposed by a scripting engine.
They don't.
Test case for using "document.write" in XHTML 1.0:
* The XHTML file:
<?xml version="1.0" encoding="UTF-8"?>
<script type='text/javascript' src='xhtml_docwrite.js'></script>
* The Javascript file:
function sayHi()
{
document.write("<h1>Hello World!</h1>");
}
If I put the page on a server that sends application/xhtml+xml headers
with it (as per XHTML specs) Mozilla 1.7rc1 interprets the page as
XHTML, builds an XHTML DOM for it, and errors with:-
Error: uncaught exception:
[Exception... "Object cannot be created in this context"
code: "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)"
location: " [...] /xhtml_docwrite.js Line: 3"]
(error messages vary slightly on earlier Mozilla versions but no
Mozilla/Gecko XHTML DOM will execute a document.write call.)
Scripting Appendix C XHTML 1.0 served as text/html as if it was HTML
(because for all practical purposes it is) will work apparently reliably
at present. I don't think it is a good idea to do so because there is
always a chance that a browser might see "<?xml ... >" at the start of a
page and decide to override the content type header in its favour,
leaving a document that might result in either an XHTML DOM or an HTML
DOM[1], and because logic alone suggests that if you want to script an
HTML DOM you should create an HTML document. I also cannot see it as a
good idea to be sending out a document for which you know the receiving
browser is going to have to put a lot of extra work into
error-correcting.
I suspect that any confidence gained from apparent success scripting
Appendix C (text/html) XHTML 1.0 will be very rudely shattered if it
ever becomes practical to use real XHTML on the Internet.
Richard.
[1] I have read a report on Usenet of a browser that did this, but it
was not a scriptable browser so its decision will not impact in this
context. It does serve to demonstrate the risk exists (assuming that the
report was accurate, it was Usenet after all).
