Re: The Return of "WaSP Asks the W3C"

* steph wrote:
>The answer? You'll have to peek at:
>http://www.webstandards.org/learn/askw3c/sep2003.html

If the document is supposed to say anything about text/xml, it should
say that people should never ever use that type. It is by the way not
correct that the rules for text/xml are more complex than those for
application/xml or application/xhtml+xml with respect to character
encoding, it the other way round, the rules for application/xml are more
complex as with text/xml you will never need to look at the content
while you have to for application/xml and derived types.

The document seems to identify tag soup as something bad. I would agree
in theory, but as a matter of fact, XHTML only works in some browsers
because they interprete the document as tag soup. XHTML documents break
in conforming HTML user agents. So without tag soup parsing, no XHTML.

I disagree that application/xml is an alternate media type for XHTML
documents.

  * XHTML user agents are not required to support this MIME type (of
    course, they are neither required to support text/html or
    application/xhtml+xml ...)

  * MIME type sniffing is considered bad practise, you can read long
    threads about it on www-tag where people complain that IE treats
    text/plain documents sometimes as text/html documents. If you
    deliver XHTML documents as application/xml you would either not
    get the results you want or you rely on MIME type sniffing which
    is a bad thing.

  * Even if MIME type sniffing is bad practise for some types and good
    practise for other types, it is undefined how to determine whether
    an application/xml document should be treated as some sort of
    application/xhtml+xml. Appendix A.1 of RFC 3023 explicitly warns
    not to do that or worse rely on specific behaivour in this regard.

  * And if it was defined you would get results you do not desire in
    some situations, i.e., if you do not want a user agent to apply
    any kind of special processing for known document types.

  * And even if this weren't issues, fragment identifiers are undefined
    for application/xml while they are defined for application/xhtml+xml
    you could thus get all sorts of unexpected results like fragment
    identifiers do not work or work differently than you expect.

Hence, for theoretical and practical matters, the document should say
that application/xml should not be used for XHTML documents.

I find it quite troublesome to refer to "content negotiation" in this
document as the "solution" does not serve different content (which
content negotiation is about) and the proposed solution for the Apache
web server, i.e. using "AddType application/xhtml+xml;qs=0.8" would
cause the web server to create an invalid HTTP response as it would send
out the 'qs' parameter which is not allowed for application/xhtml+xml.

It is also noteworthy that browser support for XHTML is, well, not
perfect. Some browser versions claiming support for XHTML do not support
the application/xhtml+xml MIME types, some which claim to support the
MIME type fail to recognize named character references such as ö
properly (some versions of Mozilla, Opera, ...) or they fail to ignore
comments such as

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title></title>
    <style type='text/css'><!--
      p { color: red }
    --></style>
  </head>
  <body>
    <p>This shall not be red</p>
  </body>
  </html>

Amaya 8.0 for example, which leads to another point, it should be more
explicit that you are likely to get unpleasant surprises if you deliver
XHTML as application/xhtml+xml as many documents claiming to be XHTML
documents rely on "features" that would not if user agents applied XHTML
rules.

Received on Friday, 5 September 2003 00:06:38 UTC