Martin Honnen wrote:
Mcginkel wrote:
I know that you cannot use write() while parsing an xhtml document. I
just assume I can write a new document once into another window or
frame. so not modifying the original doc. Is that outside the scope of
the spec ?
It is hard to find anything definitive in the spec, if we look at the
W3C DOM Level 2 HTML module then it defines a method document.write for
both HTML 4 and XHTML 1.0 documents as the introduction in
<http://www.w3.org/TR/DOM-Level-2-HTML/> says:
"This specification defines the Document Object Model Level 2 HTML, a
platform- and language-neutral interface that allows programs and
scripts to dynamically access and update the content and structure of
[HTML 4.01] and [XHTML 1.0] documents."
and as the specification of document.write in
<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75233634> does to
list any exceptions that for XHTML 1.0 the method is not supposed to be
supported.
The specification of the open method here
<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-72161170> does not
list any parameters and only speaks of strings of unparsed HTML.
So in terms of the W3C DOM the open method has no parameter to set a
MIME type.
As you have worked with XHTML. Is it worth migrating to ? The main
reason to change is the option to mix html with xml (simular to
dataislands in IE) and svg. The opinions on XHTML are quite diverse,
depending on who you speak. Is it solid enough to build appliactions in
a browser ?
My work with XHTML has been mostly experimental to explore the
differences between scripting HTML and XHTML and XML documents. My
conclusion so far is that it is not worth to bother with pure XHTML 1.0
as a replacement for HTML 4.01 as there are no advantages in terms of
HTML (XHTML 1.0 is a reformulation of HTML 4.01 and thus has the same
elements and attributes) and as writing XHTML 1.0 so that it is
backwards compatible with HTML is a hassle. With at least one major
browser (that is IE/Win) having no support for XHTML being served as
application/xhtml+xml if you want to use XHTML 1.0 you are however
forced to write in so it is backwards compatible to HTML and can be
served as text/html.
There are some people by now who use the HTTP accept header the user
agent sends to send XHTML 1.0 as text/html then to IE but as
application/xhtml+xml to browsers like Mozilla or Opera.
Scripting then even becomes more difficult as you have to write your
scripts so that they work in both environments.
And there are documented disadvantages, for instance the Mozilla web
devloper FAQ
<http://www.mozilla.org/docs/web-developer/faq.html#xhtmldiff> clearly
explains "The document is not loaded and rendered incrementally. That
is, the document is displayed only after the entire document has been
received and parsed."
So on the web in general I see no reason why you should use XHTML 1.0
instead of HTML 4.01.
If you were authoring for an intranet where you know all users using the
latest version of a browser supporting XHTML as application/xhtml+xml
you could of course decide differently, you do not have the hassle of
needing to write markup that both HTML/SGML and XHTML/XML parsers
understand and the hassle of writing scripts working in both environments.
Things are different when it comes to real advantages XHTML and XML has
to offer, you have named the integration of XHTML with other XML
applications like SVG or like MathML. There it certainly makes sense to
use XML but of course it is hardly possible to write applications for
the web in general that case, these are (at least currently) niche
applications requiring a particular user agent. Mozilla (since 1.0 I
think) can do XHTML 1.0 with MathML, Opera (since 8.0) can do XHTML 1.0
with SVG Tiny I think where script in the SVG is not supported, where no
SVG DOM is exposed, and where Core DOM manipulation of the SVG elements
at run time are not working reliably. The upcoming Firefox 1.5 will
allow mixed XHTML, MathML, SVG with scripting of SVG and some SVG DOM
exposed but obviously then writing for instance a mixed XHTML and SVG
document that works the same in Firefox 1.5 and Opera 8 needs a
developer carefully using features implemented by both browsers.
If you think XHTML helps to have then XML data islands in the HTML
document then I still think using HTML 4 and text/html for your HTML
document with script and then using your script and XMLHttpRequest to
load/parse the XML data gives you a broader browser support and easier,
more consistent scripting.
--
Martin Honnen
http://JavaScript.FAQTs.com/
It seems xhtml 1.0, of which there are transitional, strict, and frame
set species, has been the focus of this discussion. Xhtml 1.1 has been
out quite a while now and an even newer version, which will require new
browsers, is in the works. I only code in xhtml 1.1 now and see
absolutely no advantage of using a 1.0 species at this late date. Of
course what html-xhtml version you wish to use is a matter of personal
taste - even html 3.2 still works on most browsers.
It has been claimed that xhtml 1.1 can not be served as html. However,
in many cases this is not true, although there is likely no advantage
in doing so rather than using html 4.01 strict. The W3C just says xhtml
1.1 should not be served as html. However, they say that xhtml must not
be served as html. It is likely that the next version of xhtml will
specify that it must not be served as html. I suspect that the W3C did
not use "must not" for xhtml 1.1 because of IE6 and relatives that can
not accept the mime type application/xhtml-xml.
I am serving true application/xhtml+xml in some of my more recent
pages. A simple php include at the very top of the php page detects if
the browser will accept application/xhtml+xml. If so, everything needed
for xhtml 1.1 above the head tag is automatically included in the page.
If the mentioned mime type support is not detected, then code above the
page for html 4.01 strict is written. The php include also uses a
simple regular expression to convert <br /> and such to <br> if an html
page must be used.
When you use xhtml 1.1 served as application/xhtml+xml, browsers that
can handle it become very strict and parse your code as xml. If there
is the least little error, the page does not display and you get a xml
parse error message instead. In general document.write just gives a
blank page or an error message. The xml parser can see right through
script, comment tags, etc. The main xml no-no is anything that is not
closed. The problem with document.write is there is no telling what
this might contain, including unclosed tags and symbols with special
xml meaning. Thus document.write can not be allowed. In some cases you
can build up what you need from the DOM to replace document.write.
However the easy way is to use server side script. For example, I had
one old page where document.write was at the bottom of a nest of 3 if
loops and was executed about 2500 times. It was easy to convert this
portion of the script to a server side php script. Thus the browser is
sent all of the code generated by the document.write php replacement,
and the xml parser has no problem checking all of this code for
unclosed tags, etc. You can also use server side Perl or several other
languages if any of them strike your fancy more than php.
I likely will soon be posting some examples of rather complicated pages
served in both xhtml 1.1 and html 4.01 strict as needed by the viewing
browser. These pages include some server side php script. This will
hopefully make what I discussed above more clear.