Branko Collin wrote
> For some obscure reason, these three browsers seem to
> think they themselves are capable of displaying XML
> documents of non-XHTML applications. As you
> found out, this is clearly not true.
No obscurity here, but maybe a little confusion. All three browsers
claim to render
(1) html
(2) xhtml and
(3) xml when furnished with css styles indicating how the elements are to be
displayed.
All three more or less deliver on those claims, including (3) They not only
"think" they can do (3) -- i.e. "display XML documents of non-XHTML
applications" -- but they all do indeed do just that fairly well if the
required css is provided.
The original poster had two problems (though they were seen as just one)
1) How to get these browsers to display *the source* of an xml document
2) How to get that display to consist, not simply of a lexical
representation of the document source, but of a collapsible tree view.
There is no reason to complain to the developers about the fact that none of
the browsers will straightforwardly display the source of an xml (but
non-xhtml) document if sent that document without any styling information
(unless it is sent with a mime-type of text/plain). Why should they? That's
the job of an text editor, not a browser. The only thing one could
reasonably demand that they must to do with such a document if typed as
text/xml is display nothing: which is apparently precisely what Safari does.
IE6 and Mozilla/Firefox however, if sent a well-formed xml document without
styling information but mime-typed as text/xml, will internally transform it
into a textual representation in html of the source and attach css and
javascript that allows the rendered structure of the document to be
dynamically expanded or collapsed. That happens instantly with Moz/FF,
whereas in IE there is a delay dictated by the latency of the connection
involved if the document has a document type declaration that references a
DTD that needs to be fetched from a remote source. This is because, as
Wendell has explained, the MS parser handles documents that reference a DTD
differently from the Moz/FF one, although both approaches are conformant
with the spec.
As I tried to explain in my earlier response, in such circumstances what IE
or Moz/FF display is not really "the xml" at all. It is a special rendering
of that xml into html + javascript + css. So anyone who wants to deliver
such a rendering to browsers other than IE or Moz/FF can't rely on the
client browser to do the job: they have to do it themselves on the server
and send the resulting html to the client. In a project that is doing
server-side transforms anyway in order to deliver TEI documents as html,
this should not be at all difficult to achieve. All it takes is a suitable
bit of xslt. As I already indicated, a number of xslt examples that do this
are freely available. Here's one by Dave Lindquist
http://www.gazingus.org/xsl/treeview.xsl
Load that document in Moz/FF then do a view source on it to see how it is
neatly configured to transform itself when loaded by a browser capable of
client-side xslt.
By using such a script server-side , a collapsible tree view can be
delivered in a browser-independent way, provided that the browsers concerned
support css and javascript. However (and there could be an accessibility
issue here) it can't be taken for granted that all users will have browsers
that fit that bill, so it would be desirable, where a browser lacking the
necessary css/javascript support is detected, to send either the raw xml
source, typed as text-plain, or a plain-text version in which the markup has
been escaped, typing it as text/html. My own experience suggests that the
latter approach is the one most likely to work as desired with most
browsers. And it also avoids the need to make the server deliver specific
xml documents with mime-type text/plain, not an overwhelmingly difficult
task, but one which some server admins may not be willing to perform. But
neither option will give a dynamic collapsible view. For that, scripting
plus css support plus prior xml=>html transformation, either
client or server-side, is required.
Michael Beddow
http://www.gazingus.org/xsl/treeview.xsl
>
> There are three ways out of this mess, as far as I can see:
>
> - serve the documents as something else than text/xml (although it is
> not certain this will work, as webbrowsers can be amazingly stubborn
> about content negotiation);
>
> - send bug reports to the makers of the offending webbrowsers; or
>
> - send HTML documents that display the XML document (converting < to
> <, newline to <br> etc.).
>
> --
> branko collin
> [log in to unmask]
>
|
