W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Understanding the "applicable specifications" clause (was: Re: Decentralised extensibility idea (ISSUE-41))

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Thu, 21 Jan 2010 11:18:20 +0100
To: public-html@w3.org
Message-Id: <201001211118.20822.Dr.O.Hoffmann@gmx.de>
Tab Atkins Jr:

>I think that's precisely the point.  There never was any such thing as
>"XHTML served as text/html".  It was always HTML through and through,
>though some people were confused about this and believed they were
>still in some essential way serving XHTML.  It was a (un?)lucky
>coincidence that many of the differences between the HTML and XHTML
>languages are ignored when the file is interpreted as HTML.  This led
>to some unfortunate confusion when people continued to assume that
>they were actually writing XHTML and used some features that were
>*not* ignored by HTML, and in fact result in a noticeably different
>DOM than what one would expect if it were interpreted as XHTML.

Due to my daily experience with authors, such documents, which are 
claiming to be somehow XHTML have some different states:
- it contains any kind of tag soup and one cannot decide, what the
intention of the author is, just looking in the source code without further
discussion
- the document content itself looks like HTML and has the wrong doctype
(due to some copy and paste mistakes)
- the document is proper XHTML and the server sends it as 
application/xhtml+xml
- the document is proper XHTML, therefore everything is ok with it,
until a server starts to send it out to a browser claiming it is text/html
due to some settings in configurations files of the server, that is not
looking into the files to determine the correct content type.
- it is a (PHP) script with browser sniffing, serving always the same
(im)proper XHTML content. If it gets the impression, that the browser
is able to interprete XHTML, the type application/xhtml+xml is
chosen, else it is served unchanged as buggy text/html, because
the experience is, that those browsers, who cannot understand XHTML
have a HTML-tag-soup-parser not reporting such errors anyway and
the idea is, that the audience using this browser gets some 
presentation is better than none.
- ...

Anyway once an author managed to produce some proper XHTML
document it does not mutate suddenly with a legerdemain into
HTML. Just in some cases it is only served as text/html with the known result,
that it cannot (and due to the priority of the server hint should not) 
be interpreted as XHTML. If (X)HTML is served as text/plain, surely
it should not be interpreted as (X)HTML either, just because the intention
of the author is obviously, that the audience gets the source code 
presented and  not interpreted, for example pretty useful for tutorials
(I use this method myself quite often).
It is, was is noted inside the document with an optional doctype, 
a namespace and a version indication. 
But it is maybe interpreted/presented in another way for some reason.

Olaf
Received on Thursday, 21 January 2010 10:40:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:00 GMT