William F Hammond wrote:
1. Many search engines appear not to look at application/xhtml+xml.
That seems like a much simpler thing to fix in search engines than in
the specification and UAs, to be honest. I don't see this as a
compelling reason to add complexity to the parsing model.
2. Many content providers have reported that they are stranded,
i.e., their contractors who receive the content by "upload" for
subsequent placement under the eye of an http server do not
support application/xhtml+xml.
This is the argument for any type of content-type sniffing, no? By this
argument, why bother with MIME types at all?
(And, of course, "text/xml" and "application/xml" are non-specific
mimetypes for which there is no base namespace. They are sane content
channels for web browsers only when display is entirely controlled
with something like CSS.)
Uh... Have you tested this? As I recall there are no major
layout/rendering differences in Gecko, Opera, and Safari between an
XHTML document sent as application/xhtml+xml and one sent as
application/xml. In both cases, it needs to have the XHTML namespace on
all the nodes to be handled "correctly". There are differences in terms
of the DOM: the document doesn't necessarily implement the HTMLDocument
interface. HTML5 proposes to change that so that all Documents
implement HTMLDocument if the UA supports HTMLDocument at all. At that
point it really won't matter whether XHTML is served as
application/xhtml+xml from a DOM point of view. There might be a new
behavior difference introduced if the <body> background special-casing
in CSS is extended to apply to application/xhtml+xml like it applies to
text/html now. But I'd hardly call application/xml delivery of XHTML
"insane" now, and even less so after the HTMLDocument change is made.
If you're talking about UAs other than those three that support
application/xhtml+xml, I'll admit to not knowing what the situation is
with those.
-Boris
-Boris
