Re: text/html for xml extensions of XHTML

On Fri, 4 May 2001, William F. Hammond wrote:
>
> Ian Hickson <ian@hixie.ch> writes:
>
>> is remarkably simple [1]. Apart from the idea of a magic comment header
>> and the idea of using the XML PI, both of which have problems as I have
>> remarked in the recent past on this list, all other types of sniffing that
>> have been suggested are extremely involved.
>
> A day or two ago you said that handling an item beginning with the
> xml declaration was manageable although you said that you were opposed
> to doing it.  But you did not say why.
>
> Please clarify.

As I understand it there are four different reason to do want to do this:

1. Inability to configure servers to send content as text/xml.

   Fix the server, or if that is not possible, fix the process or
   politics behind the inability to fix the server. Adding text/xml to the
   content types supported by servers is a one line change to the servers'
   configuration file.


2. Wanting to send XHTML with namespaced content to old browsers.

   These documents will not be properly processed by older browsers
   anyway, so just do what people do with PDF, frames, and so on, which is
   to provide alternative versions for older browsers, or have an
   introductory page explaining the requirements to view the content.


3. Wanting to send pure XHTML to new browsers as XML and old browsers as HTML.

   New browsers will also handle the XHTML file if it is sent as HTML, so
   there is no need to add sniffing code to the browsers to handle this case.


4. A bug in IE causes it to mishandle XHTML documents with namespaced
   content when it is sent as text/xml.

   This is a bug in IE and should not be fixed by other browsers which are
   handling things per the specs.


In addition, there are several reasons why this is a bad idea in
the first place:

A. content sniffing as a whole is a flawed concept, as demonstrated by the
   problems found with MacIE, WinIE, and Mozilla having "quirks" vs
   "standard" modes based on the DOCTYPE of HTML documents.

B. the specs do not specify how (or whether) to try to detect XML in
   text/html data streams.

C. The XML PI is optional and causes problems with some older browsers
   when present, so would be a bad trigger to use. All other proposal
   except for a "magic comment" are hard to parse quickly. The "magic
   comment" idea, while being the only one that might work, still doesn't
   address any of the other points discussed here.

D. The Content-Type HTTP header is supposed to be the final word on how to
   handle a data stream.

E. The XHTML spec only gives one reason to send XHTML as text/html, and
   that's for compatability with older browsers (see point 3 above).
   It is doubtful wether documents that don't follow the spirit of these
   guidelines (e.g. by including MathML) should be allowed to be sent as
   text/html at all.

HTH,
-- 
Ian Hickson                                            )\     _. - ._.)   fL
Invited Expert, CSS Working Group                     /. `- '  (  `--'
The views expressed in this message are strictly      `- , ) -  > ) \
personal and not those of Netscape or Mozilla. ________ (.' \) (.' -' ______

Received on Friday, 4 May 2001 08:02:00 UTC