XHTML Problems

[jp29]

My take on problems composing, serving and rendering XHTML
documents/web pages:

1. Typical conscientious web authors are producing XHTML documents (Web
pages) that feature valid Markup and with the content (MIME) type
specified as text/html
(http://keystonewebsites.com/articles/mime_type.php). These pages are
then loaded on to their Server where they are served to Rendering
Agents (browsers) as HTML (SGML application) documents with no problem
-- most Web Service Provider implementations associate HTML documents
with the content (MIME) type text/html. These pages are rendered
successfully by all extant graphical browsers -- but they are not XHTML
documents -- they are HTML documents without XML functionality
(http://hixie.ch/advocacy/xhtml). HTML documents that include DocType
declarations display in standards mode -- those that do not display in
"quirks (non-standard) mode. MSIE browsers render XHTML documents that
include the XML declaration in "quirks" mode, therefor, it seems the
declaration should be omitted for XHTML documents served as HTML --
although the W3C doesn't do so on their Home page.

2. Web authors who produce XHTML documents (Web pages) that feature
valid Markup and with the content (MIME) type specified as
application/xhtml+xml (prescribed by the W3C) inevitably face serious
problems (http://www.w3.org/International/arti...erving-xhtml/).
Most Web Service Provider implementations do not recognize this content
(MIME) type. In that event, the web author must contact his or her Web
Service Provider to try and convince them to adopt
application/xhtml+xml as the content (MIME) type to associate with
XHTML documents.If that doesn't work -- and it often doesn't -- then
the web author is faced with the task of producing and loading up to
the server a .htaccess file that provides the association -- a tricky
endeavor for many web authors. But the problems do not end there.
Current XML compliant browsers such as Mozilla, Netscape, Opera, et al.
retrieve and render these pages with no problem. However, older
browsers -- and more importantly by far -- the most frequently used
graphical browsers today -- MSIE 5.x/6.x -- will not render these
documents correctly. MSIE presents them as Down Load files and there is
no backward compatibility for older browsers
(http://www.w3.org/People/mimasa/test...-types/results)

3. This situation is a dilemma for web authors -- and the W3C. The W3C
has attempted to resolve this situation by installing a facility called
Content-Negotiation on their Server (to be a model for others?) that is
supposed to offer a choice of content (MIME) type text/html or
application/xhtml+xml XHTML documents to browsers so that they can
render them according to their capabilities
(http://www.w3.org/2003/01/xhtml-mime...t-negotiation). The
idea is to provide backward compatibility for older browsers and
accommodate current non XML compliant MSIE browsers. Of course, all
these would be HTML documents -- not XHTML documents. In theory, XML
compliant browsers would be served fully functional XHTML documents.
The W3C offers their Home page as an exemplar of this functionality.
BTW, the W3C Content Negotiation page only addresses the Apache Server
implementation in depth, Jigsaw only briefly and others such as Zeus
not at all.

4. The above procedure is not working for me. The page displays
correctly in my (XML compliant) Mozilla Firefox browser, but when I run
it through the W3C Markup validator the Content-Type displays as
text/html -- it is not being served as an XHTML document as intended.
Of course, if the W3C fix did work, the pages would still only be
served as HTML. It seems to me these problems must be sorted out ASAP
by the W3C -- certainly before they release XHTML 2.0. Now if only
Microsoft would produce a browser (and offer modifications to their
existing ones) to recognize content (MIME) type application/xhtml+xml
and serve real XHTML documents -- just like Firefox, Opera, et al. do!

James Pickering
Pickering Pages
http://www.jp29.org/

[James Pickering]

David Dorward wrote:

...... The markup validator does not appear to send an accept header
......

The extended interface does:

http://validator.w3.org/detailed.html

James Pickering
http://www.jp29.org/

[Michael Winter]

On 03/07/2005 21:52, James Pickering wrote:

[snip]

David Dorward wrote:

The markup validator does not appear to send an accept header

David is correct.

[snip]
Try:

http://www.web-caching.com/showheaders.html

That will show you what headers the *query page* sends in response, but
now what the validator sends in its request. To do that, you should
write a short server-side script that outputs the request headers, then
point the validator to it with the 'Show Source' option selected.

There were no Accept headers of any kind in my test.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Andy Dingley]

On Sun, 03 Jul 2005 21:35:20 +0200, Benjamin Niemann <pi**@odahoda.d e>
wrote:

Why not use .html and .xhtml?

It tends to unstable URLs for the pages. A URI should refer to the
resource, not to irrelevant (for the source of the link) details of its
implementation.

A site with a mix of .html and .xhtml extensions in the links would be a
nightmare to manage, even worse if pages were gradually changing from
one to the other.

There nay be some clever Apache-fu that works around this, serving
either file extension under the same URI, depending on the presence of
files with particular extensions.

[Tim]

Benjamin Niemann <pi**@odahoda.d e> wrote:

Why not use .html and .xhtml?

Andy Dingley wrote:
It tends to unstable URLs for the pages. A URI should refer to the
resource, not to irrelevant (for the source of the link) details of its
implementation.

A site with a mix of .html and .xhtml extensions in the links would be a
nightmare to manage, even worse if pages were gradually changing from one
to the other.
Are one of you talking about filenames, and the other about URIs? You can
have both filenames in use (depending on content), and not refer to the
filename specifically with requests (i.e. sans-suffix).

e.g. Request http://example.com/pagename
And get pagename.html or pagename.xhtml, depending on what's stored
on the server, and what suits the browser (should there be a choice).
There nay be some clever Apache-fu that works around this, serving either
file extension under the same URI, depending on the presence of files with
particular extensions.

"Content negotiation"

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[David Dorward]

Henri Sivonen wrote:

In article <da************ *******@news.de mon.co.uk>,
David Dorward <do*****@yahoo. com> wrote:

Yes, well, GoogleBot, Safari, Konqueror, Links, Lynx, and W3M don't
support XHTML yet either AFAIK.

Safari supports XHTML as application/xhtml+xml but does not advertise it
in the Accept header.

I don't have a copy of Safari to hand for testing, but Konqueror (the open
source cousin to Safari) accepts an application/xhtml+xml content-type ...
but then shoves it through a tag soup slurper rather then an XML parser. It
renders http://dorward.me.uk/tmp/error.xhtml despite the well-formedness
errors.

--
David Dorward <http://blog.dorward.me .uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Andy Dingley]

On Mon, 04 Jul 2005 13:58:51 +0900, Tim <ti*@mail.local host.invalid>
wrote:

Are one of you talking about filenames, and the other about URIs?
I'm talking about both. Two sorts of file extension is good, as it
labels the content. Two sorts of extension embedded in the URL is bad,
as it makes link-management messy.

If there's some means of solving both situations (i.e. distinguishing
them when we talk about files, hiding it when we talk about URLs) then
we can avoid these problems.

You can
have both filenames in use (depending on content), and not refer to the
filename specifically with requests (i.e. sans-suffix).

e.g. Request http://example.com/pagename
And get pagename.html or pagename.xhtml, depending on what's stored
on the server, and what suits the browser (should there be a choice).

My Apache-fu is weak.

Is it practical to do this when there's only one file (.xhtml) and the
browser wants only text/html ? I know the server can choose to serve a
..html file instead of the .xhtml, but AFAIK this would require two
copies of the content on the server.

What I'm looking for is content negotiation that can silently choose to
deliver either XHTML, or Appendix C XHTML-as-HTML, according to browser
acceptance. Is this possible ? Would you happen to have an example of
it that we might learn from ?

[Alan J. Flavell]

On Mon, 4 Jul 2005, Andy Dingley wrote:

On Mon, 04 Jul 2005 13:58:51 +0900, Tim <ti*@mail.local host.invalid>
wrote:

Are one of you talking about filenames, and the other about URIs?
I'm talking about both. Two sorts of file extension is good, as it
labels the content. Two sorts of extension embedded in the URL is
bad, as it makes link-management messy.

I'm not sure exactly what that's supposed to mean, but for any reader
who isn't accustomed to your style, may I just stress that in WWW
terms, the content-type of anything retrieved by HTTP is determined by
the HTTP Content-type header, and the file "extension" does not play
any *direct* role in that interworking interface. [Sure, within the
actual server it may very well be that the *server itself* uses the
file "extension" as a way of labelling the content-type; the key
feature is that this is not part of the defined HTTP interworking
interface between the server and the client.] You knew all that, of
course, I'm just worried that some readers might be confused about it,
and perhaps exacerbated by MSIE's violation of RFC2616, and MS's
mischievous citation of RFC2616 in the part of their documentation
where they describe, without admitting it, that they are in violation
of this mandatory requirement.

[...]
Is it practical to do this when there's only one file (.xhtml) and
the browser wants only text/html ? I know the server can choose to
serve a .html file instead of the .xhtml, but AFAIK this would
require two copies of the content on the server.
My experiments with Apache 1.3.* showed that strange things could
sometimes happen with MultiViews, but generally speaking, a symlink
would be sufficient, you wouldn't need literally two copies. If you
work via a type-map file (which could be written programmaticall y, e.g
as part of your publish-to-web process in a makefile), then you can
eliminate even this part of the problem.
What I'm looking for is content negotiation that can silently choose
to deliver either XHTML, or Appendix C XHTML-as-HTML, according to
browser acceptance.
I understand you here to mean delivering the same actual file with
different content-type headers as the outcome of content negotiation,
right?
Is this possible ?

It's definitely possible, yes. However, since I wrote the relevant
pages (which were concentrating on language negotiation rather than on
content-type negotiation, but the principle is closely similar), we've
moved our server from Apache 1.3.* to 2.0.*, so I can't offer you a
100% convincing demonstration yet - all that I can offer you is an
assurance that it can be done. As I say, if MultiViews proves
intractable for your purpose (I'm not absolutely sure if this is so or
not), then using a type-map file will, I am convinced, offer a
solution.

http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html

see also http://ppewww.ph.gla.ac.uk/~flavell/...tent-type.html

good luck

[James Pickering]

I solicit comments on the following article:

http://insight.zdnet.co.uk/internet/...2135615,00.htm

[Steve Pugh]

"James Pickering" <jp**@cox.net > wrote:

I solicit comments on the following article:

http://insight.zdnet.co.uk/internet/...2135615,00.htm

Hmm, comments. It's a two year old article and I don't see the
relevance to this thread about XHTML and content-type headers in
general and to Alan's post in particular.

Steve

--
"Grab reality by the balls and squeeze." - Tempus Thales

Steve Pugh <st***@pugh.net > <http://steve.pugh.net/>

[Andy Dingley]

On 4 Jul 2005 10:09:11 -0700, "James Pickering" <jp**@cox.net > wrote:

I solicit comments on the following article:

How about "completely irrelevant" ?