lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] Encoding


From: David Woolley
Subject: Re: [Lynx-dev] Encoding
Date: Mon, 6 Mar 2006 21:40:34 +0000 (GMT)

> >Most people serve XHTML as text/html for unsound, usually fashion reasons.
> 
> Such "unsound, fashion reasons" as the XHTML standard
> itself recommending it?

Laying aside that there isn't an XHTML standard, the XHTML reccommendation
document does not recommend the use of text/html.  In itself it is
a little confused about its use of standards language, and whilst it
says "may" (subject to appendix C conformance, of which more later),
which means discouraged, but permitted, the current version refers
to the XHTML Media Types technical report.  That, in section 3.1,
<http://www.w3.org/TR/xhtml-media-types/#3_1>, makes it clear that the use
of text/html is not particularly desirable, and it its summary of allowed
combinations clearly says that the SHOULD case (i.e.  the recommended
case) is application/xhtml-xml, and that text/html is only a MAY.

The whole point of the appendix C rules is that such documents should
work with de facto unmodified HTML clients, not that it should work with
specially XHTML aware clients.  (It won't work with de jure unmodified
clients, because there a fundamental conflicts between XML and SGML
at the lexical level.)  Failure to work with Lynx is therefore a prima
facie indication of a broken document, and given that the document could
only work in an XML aware user agent (or with a manually set encoding),
I'd say that the case against the document was proven.

Examination of the XHTML recommendation confirms this, as it makes
the inclusion a meta html charset mandatory ("must") in any appendix
C document that overrides the character set and doesn't have an
HTTP charset.  <http://www.w3.org/TR/xhtml1/#text-html>.

> I'm simply asking Lynx to honour the encoding in the xml tag of
> XHTML documents (at least if served as text/html) as a sort of
> "last resort".

Could I suggest that if anyone does implement this, they throw an
invalid document alert if it doesn't match the encoding obtained from
HTML sources, as such documents *are* invalid.

For some more information on why serving XHTML 1.0 as text/html,
rather than using HTML 4.01, I refer you to this paper by an
industry expert:

Sending XHTML as text/html Considered Harmful
<http://www.hixie.ch/advocacy/xhtml>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]