XHTML 1.1 and browser compatibility

[Mark Tranchant]

My site now uses Apache MultiViews and some PHP code to determine whether
your browser can handle the application/xhtml+xml media type.

If it does, the document is sent with that content type and the XHTML 1.1
DOCTYPE. If not, it is sent as text/html and the XHTML 1.0 DOCTYPE.

Details of how this is achieved and the problems solved en route can be
seen in these two pages:

http://tranchant.plus.com/notes/xhtml11
http://tranchant.plus.com/notes/multiviews

What I'd like to know, though, is whether this causes any problems for more
obscure browsers using badly-chosen Accept headers.

Please try the site and let me know if it gives you any problems.

Thanks!

--
Mark.
http://tranchant.plus.com/

[Spartanicus]

Mark Tranchant <ma**@tranchant.plus.com> wrote:

My site now uses Apache MultiViews and some PHP code to determine whether
your browser can handle the application/xhtml+xml media type.

Please try the site and let me know if it gives you any problems.

Opera (7.5p3) gets 1.0, search this group for earlier discussions on
content negotiation on how to do this proper.

--
Spartanicus

[Bertilo Wennergren]

Mark Tranchant:

My site now uses Apache MultiViews and some PHP code to determine whether
your browser can handle the application/xhtml+xml media type. If it does, the document is sent with that content type and the XHTML 1.1
DOCTYPE. If not, it is sent as text/html and the XHTML 1.0 DOCTYPE. Details of how this is achieved and the problems solved en route can be
seen in these two pages: http://tranchant.plus.com/notes/xhtml11
http://tranchant.plus.com/notes/multiviews What I'd like to know, though, is whether this causes any problems for more
obscure browsers using badly-chosen Accept headers.

There can be problems since your PHP code that chooses the content type
is too simple. It only checks for the presence of the string
"application/xhtml+xml" in the Accept header. That's a very common
practice, but not correct. You have to check at least the "q" values for
"text/html" and "application/xhtml+xml", and then compare those to see
which content type the user agent prefers. If it has a preference for
"text/html", then it might be that it can't handle XHTML 1.1 very well.
If you're interested I could give you my own PHP code. I'm not sure it's
perfect, but it's probably a bit better.

Another problem is that the XHTMl 1.0 version you're serving is not done
entirely according to the HTML Compatibility Guidelines that should be
followed when serving XHTML 1.0 as "text/html". Actually I only saw one
such issue in your pages, and it might not be a big problem in practice,
but since it seems you're trying to do things correct to the last dot,
you should probably try to correct that one too. Here's what the XHTML
1.0 Specification says:

C.7. The lang and xml:lang Attributes

Use both the lang and xml:lang attributes when specifying the language
of an element. The value of the xml:lang attribute takes precedence.
xml:lang="en"

<URL:http://www.w3.org/TR/xhtml1/#guidelines>

There might be other similar issues in your pages.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Mark Tranchant]

Bertilo Wennergren wrote:

My site now uses Apache MultiViews and some PHP code to determine whether
your browser can handle the application/xhtml+xml media type.

If it does, the document is sent with that content type and the XHTML 1.1
DOCTYPE. If not, it is sent as text/html and the XHTML 1.0 DOCTYPE.

There can be problems since your PHP code that chooses the content type
is too simple. It only checks for the presence of the string
"application/xhtml+xml" in the Accept header. That's a very common
practice, but not correct.
Yeah, I know. I need to update that page, as if you read to the bottom
you'll see a note explaining that I now let Apache read the Accept header
and choose which of two files to serve. In reality, these two files are the
same, and my PHP code uses the chosen filename to determine which one
Apache chose.

In other words, my PHP does not parse the Accept header.
Another problem is that the XHTMl 1.0 version you're serving is not done
entirely according to the HTML Compatibility Guidelines that should be
followed when serving XHTML 1.0 as "text/html". Actually I only saw one
such issue in your pages, and it might not be a big problem in practice,
but since it seems you're trying to do things correct to the last dot,
you should probably try to correct that one too. Here's what the XHTML
1.0 Specification says:

C.7. The lang and xml:lang Attributes

Use both the lang and xml:lang attributes when specifying the language
of an element. The value of the xml:lang attribute takes precedence.
xml:lang="en"

I'm aware of that one. My problem is that lang does not appear in XHTML
1.1, so I'd need to extend my document modification to cover that too.

I *believe* (although I'm open to correction) that just specifying xml:lang
does not contravene XHTML 1.0 rules?

Thanks for pointing this out. Maybe I should switch to XSLT-generated
content, starting from bespoke XML or XHTML 2.0...

--
Mark.
http://tranchant.plus.com/

[Mark Tranchant]

Spartanicus wrote:

Mark Tranchant <ma**@tranchant.plus.com> wrote:

My site now uses Apache MultiViews and some PHP code to determine whether
your browser can handle the application/xhtml+xml media type.

Please try the site and let me know if it gives you any problems.

Opera (7.5p3) gets 1.0, search this group for earlier discussions on
content negotiation on how to do this proper.

I have researched extensively. I'm pretty sure my implementation is best.
Note that I do not use the PHP parsing of the Accept header described as a
simplistic solution on http://tranchant.plus.com/notes/xhtml11 (updated
since you viewed it).

Instead, I let MultiViews parse the Accept header, decide on a file, and
modify my output dependent on its choice.

If you think there's something wrong with that, let me know. What Accept
header does Opera 7.5 send?

--
Mark.
http://tranchant.plus.com/

[Bertilo Wennergren]

Mark Tranchant:

Bertilo Wennergren wrote:

There can be problems since your PHP code that chooses the content type
is too simple. It only checks for the presence of the string
"application/xhtml+xml" in the Accept header. That's a very common
practice, but not correct. Yeah, I know. I need to update that page, as if you read to the bottom
you'll see a note explaining that I now let Apache read the Accept header
and choose which of two files to serve. In reality, these two files are the
same, and my PHP code uses the chosen filename to determine which one
Apache chose.
OK. I hope Apache does it right. It probably does.
C.7. The lang and xml:lang Attributes Use both the lang and xml:lang attributes when specifying the language
of an element. The value of the xml:lang attribute takes precedence.
xml:lang="en"

I'm aware of that one. My problem is that lang does not appear in XHTML
1.1, so I'd need to extend my document modification to cover that too.
Indeed. That you should do. Otherwise you shouldn't serve the pages as
"text/html".
I *believe* (although I'm open to correction) that just specifying xml:lang
does not contravene XHTML 1.0 rules?
It contradicts the compatibility guidelines, and if you don't follow
those guidelines you should serve your XHTMl 1.0 as "application/xhtml+xml".
Thanks for pointing this out. Maybe I should switch to XSLT-generated
content, starting from bespoke XML or XHTML 2.0...

You could use some PHP hacks to modify the code (adding the missing
"lang" attributes as needed). I'm not sure how you could make PHP lock
into the media type choice made by Apache though...

That's why I do all this in PHP. But it's not easy!

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Alan J. Flavell]

On Mon, 19 Apr 2004, Mark Tranchant wrote:

Instead, I let MultiViews parse the Accept header, decide on a file, and
modify my output dependent on its choice.
Good move...
If you think there's something wrong with that, let me know.

If there =is= something wrong with that, then it's Apache's fault
rather than Mark's ;-)

[Spartanicus]

Mark Tranchant <ma**@tranchant.plus.com> wrote:

What Accept header does Opera 7.5 send?

Accept: text/html, multipart/mixed, application/xml;q=0.9,
application/xhtml+xml;q=0.9, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1

--
Spartanicus

[Mark Tranchant]

Bertilo Wennergren wrote:

I'm aware of that one. My problem is that lang does not appear in XHTML
1.1, so I'd need to extend my document modification to cover that too.

Indeed. That you should do. Otherwise you shouldn't serve the pages as
"text/html".
OK, that was easier than expected. Now serving lang + xml:lang for 1.0 and
xml:lang for 1.1.
I *believe* (although I'm open to correction) that just specifying xml:lang
does not contravene XHTML 1.0 rules?

It contradicts the compatibility guidelines, and if you don't follow
those guidelines you should serve your XHTMl 1.0 as "application/xhtml+xml".
Point taken, now fixed.
You could use some PHP hacks to modify the code (adding the missing
"lang" attributes as needed). I'm not sure how you could make PHP lock
into the media type choice made by Apache though...

Read my pages. I use a .phtml file as the content, and symlink a .pxhtml
file to it. Apache is told to consider .phtml as text/html and .pxhtml as
application/xhtml+xml. All URLs are provided without extension: any attempt
to link to one with extension will redirect to the plain version.

MultiViews then chooses one of the two files based on its parsing of the
Accept header. The chosen filename is then available for me in PHP's
$_SERVER['SCRIPT_FILENAME'] variable, and can be used to determine which
type Apache chose.

Elegant, fairly simple, and all server-side. I can't see any downsides to
my current implementation, but this group is excellent at pointing out
disadvantages.

--
Mark.
http://tranchant.plus.com/

[Mark Tranchant]

Spartanicus wrote:

Mark Tranchant <ma**@tranchant.plus.com> wrote: Accept: text/html, multipart/mixed, application/xml;q=0.9,
application/xhtml+xml;q=0.9, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1

There's your answer. Although it *can* accept application/xhtml+xml, it
prefers text/html, which is what I serve it.

The simplistic solution presented on my xhtml11 page would have given you
the 1.1-compliant page, but my real solution does it correctly and provides
you with the 1.0 page.

Firefox presents an Accept header of:

.... application/xhtml+xml,text/html;q=0.9 ...

which is the other way around, so it gets the 1.1 page.

--
Mark.
http://tranchant.plus.com/

[Alan J. Flavell]

On Mon, 19 Apr 2004, Mark Tranchant wrote:

Bertilo Wennergren wrote:

Another problem is that the XHTMl 1.0 version you're serving is not done
entirely according to the HTML Compatibility Guidelines that should be
followed when serving XHTML 1.0 as "text/html". Actually I only saw one
such issue in your pages, and it might not be a big problem in practice,
but since it seems you're trying to do things correct to the last dot,
you should probably try to correct that one too. Here's what the XHTML
1.0 Specification says:

C.7. The lang and xml:lang Attributes

Use both the lang and xml:lang attributes when specifying the language
of an element. The value of the xml:lang attribute takes precedence.
xml:lang="en"

However, if the client agent says it prefers XHTML, there's no need to
conform with Appendix C; whereas, if the client agent says/implies
that it prefers HTML, I don't see any need to provide it with
something (xml:lang) that's specific to XHTML.
Thanks for pointing this out. Maybe I should switch to XSLT-generated
content, starting from bespoke XML or XHTML 2.0...

No arguments there, but I'm not the one who's planning to do the work
of implementing it. ;-)

[Alan J. Flavell]

On Mon, 19 Apr 2004, Bertilo Wennergren wrote:

I'm not sure how you could make PHP lock
into the media type choice made by Apache though...

As Mark already said: if you use MultiViews (Apache 2):

| use PHP’s $_SERVER['SCRIPT_FILENAME'] to find which of the two files
| MultiViews chose.

http://tranchant.plus.com/notes/multiviews

There's also a solution if you use typemaps - I'll write it up on my
page when I get around to it. I can't see a way to get Multiviews to
work for PHP in Apache 1.3 (because PHP isn't available as a "handler"
there, and the magic content-type has to be used), but the type-map
solution can be used in either kind of Apache.

[Mark Tranchant]

Alan J. Flavell wrote:

Bertilo Wennergren wrote:

C.7. The lang and xml:lang Attributes

Use both the lang and xml:lang attributes when specifying the language
of an element. The value of the xml:lang attribute takes precedence.
xml:lang="en"

However, if the client agent says it prefers XHTML, there's no need to
conform with Appendix C; whereas, if the client agent says/implies
that it prefers HTML, I don't see any need to provide it with
something (xml:lang) that's specific to XHTML.

The "need" is that I want the same code to conform to both 1.0 Appendix C
and 1.1. Now I've had to make dynamic document changes to accommodate the
incompatibility of the lang attribute across versions, I will probably end
up going the whole hog and serving either HTML 4.01 or XHTML 1.1.

I know you're not a great fan of XHTML 1.0 with Appendix C, so I'm sure
you'll appreciate this!

--
Mark.
http://tranchant.plus.com/

[Bertilo Wennergren]

Mark Tranchant:

Bertilo Wennergren wrote:

You could use some PHP hacks to modify the code (adding the missing
"lang" attributes as needed). I'm not sure how you could make PHP lock
into the media type choice made by Apache though...

Read my pages.
I did afterwards. (Sorry!)
I use a .phtml file as the content, and symlink a .pxhtml
file to it. Apache is told to consider .phtml as text/html and .pxhtml as
application/xhtml+xml. All URLs are provided without extension: any attempt
to link to one with extension will redirect to the plain version.
A good setup.
MultiViews then chooses one of the two files based on its parsing of the
Accept header. The chosen filename is then available for me in PHP's
$_SERVER['SCRIPT_FILENAME'] variable, and can be used to determine which
type Apache chose.
So you use some search and replace then to add the "lang" attributes, I
guess.
Elegant, fairly simple, and all server-side. I can't see any downsides to
my current implementation, but this group is excellent at pointing out
disadvantages.

I you use search and replace to massage the code into HTML compatibility
compliance, then watch out for unwanted replacements. I have some pages
that talk about XHTML code, and I've had my search and replace routines
do some bad stuff with my code examples that should not be touched.
Actually I serve HTML 4.01 to browsers that prefer "text/html", so I
just remove the "xml:" part from the "xml:lang" attributes. That
sometimes made my XHTML tutorial talk about "lang" where it should talk
about "xml:lang". I ended up writing the "x" in "xml:" as a numerical
character reference in the code examples.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Brian]

Mark Tranchant wrote:

I will probably end up going the whole hog and serving either HTML
4.01 or XHTML 1.1.

May I ask why you decided to offer two variants? It's a neat idea, don't
get me wrong. But what advantages do you get with the xhtml 1.1 version
of your documents?

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[Brian]

Mark Tranchant wrote:

All URLs are provided without extension: any attempt to link to one
with extension will redirect to the plain version.

May I ask how you did this? I tried what seemed obvious to me:

RedirectMatch (.*)\.html$ $1

When combined with multiviews, it resulted in a 404 error on all urls,
and a 302 found error while trying to use ErrorDocument.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[Mark Tranchant]

Brian wrote:

All URLs are provided without extension: any attempt to link to one
with extension will redirect to the plain version.

May I ask how you did this? I tried what seemed obvious to me:

RedirectMatch (.*)\.html$ $1

When combined with multiviews, it resulted in a 404 error on all urls,
and a 302 found error while trying to use ErrorDocument.

Close, but no cigar. The target argument must be a fully-qualified URL,
whereas the requested URL is relative to the root of the current site.

It would also be better to define this as a permanent redirect, to avoid
anyone caching or indexing the extension-ed URL.

I use this:

RedirectMatch permanent /(.*)\.html$ http://tranchant.plus.com/$1

--
Mark.
http://tranchant.plus.com/

[Mark Tranchant]

Brian wrote:

Mark Tranchant wrote:

I will probably end up going the whole hog and serving either HTML
4.01 or XHTML 1.1.

May I ask why you decided to offer two variants? It's a neat idea, don't
get me wrong. But what advantages do you get with the xhtml 1.1 version
of your documents?

Primarily bragging rights at this juncture. There are some advantages to
XHTML-1.1 though:

1) Automatic validation in Mozilla and Firefox browsers, which will throw
an error message if the document is not well-formed XML.

2) Easier programmatic conversion from valid XHTML to other XML variants
than with arbitrary valid HTML, although *my* HTML always uses lower-case
tags and attributes, quotes attributes and closes all tags except empty one.

3) err... can't think of any more.

--
Mark.
http://tranchant.plus.com/

[David Dorward]

Mark Tranchant wrote:

Primarily bragging rights at this juncture. There are some advantages to
XHTML-1.1 though:

1) Automatic validation in Mozilla and Firefox browsers, which will throw
an error message if the document is not well-formed XML.

It will only check the XML for well formedness, it won't check the XHTML
itself.

http://dorward.me.uk/tmp/html-element.xhtml, for example, will not throw an
error despite the presence of a <fake></fake> in the middle of it.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>

[Spartanicus]

Mark Tranchant <ma**@tranchant.plus.com> wrote:

There are some advantages to XHTML-1.1 though:

1) Automatic validation in Mozilla and Firefox browsers, which will throw
an error message if the document is not well-formed XML.
Well formed != Valid.
3) err... can't think of any more.

Here's a drawback: Gecko can't incrementally render XML, to satisfy the
"a UA must throw a parsing error when encountering malformed code"
demand it only renders after the entire document has finished
downloading and has been parsed.

--
Spartanicus

[Mark Tranchant]

David Dorward wrote:

Mark Tranchant wrote:

Primarily bragging rights at this juncture. There are some advantages to
XHTML-1.1 though:

1) Automatic validation in Mozilla and Firefox browsers, which will throw
an error message if the document is not well-formed XML.

It will only check the XML for well formedness, it won't check the XHTML
itself.

I knew this would happen the instant I pressed Send on the original. You're
quite right, I should have written "Automatic validation of XML
well-formedness".

--
Mark.
http://tranchant.plus.com/

[Mark Tranchant]

Spartanicus wrote:

Here's a drawback: Gecko can't incrementally render XML, to satisfy the
"a UA must throw a parsing error when encountering malformed code"
demand it only renders after the entire document has finished
downloading and has been parsed.

Hmmm. I'd not realised that, but you must be right. Doesn't seem to be an
issue for my site, as I keep the size of my pages small and use mod_gzip on
the output.

--
Mark.
http://tranchant.plus.com/

[Brian]

Mark Tranchant wrote:

Brian wrote:

RedirectMatch (.*)\.html$ $1
The target argument must be a fully-qualified URL, whereas the
requested URL is relative to the root of the current site.

Yep, I knew that, but apparently my brain was on break when I first
tried it.
It would also be better to define this as a permanent redirect, to
avoid anyone caching or indexing the extension-ed URL.
Good point; I've changed that.
I use this:

RedirectMatch permanent /(.*)\.html$ http://tranchant.plus.com/$1

Still no cigar.

RedirectMatch permanent /(.*)\.html$ http://tsmchughs.localhost/$1

This produces a 404 error on all pages, with an additional 301 error
trying to use ErrorDocument. :(

Entering http://tsmchughs.localhost/site/help.html in the location bar
does redirect to http://tsmchughs.localhost/site/help, but then I get a
404 error. When go to the home page, http://tsmchughs.localhost/, I get
redirected to http://tsmchughs.localhost/index, again with 404. It seems
that, somehow, it isn't playing nice with multiviews.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

[Mark Tranchant]

Brian wrote:

RedirectMatch permanent /(.*)\.html$ http://tsmchughs.localhost/$1

This produces a 404 error on all pages, with an additional 301 error
trying to use ErrorDocument. :(

Entering http://tsmchughs.localhost/site/help.html in the location bar
does redirect to http://tsmchughs.localhost/site/help, but then I get a
404 error. When go to the home page, http://tsmchughs.localhost/, I get
redirected to http://tsmchughs.localhost/index, again with 404. It seems
that, somehow, it isn't playing nice with multiviews.

Are you sure you have MultiViews switched on for that section of your
filespace? Mail me your httpd.conf if you'd like me to take a look.

You must load the mod_negotiation module, and explicitly turn on MultiViews
with "Options +MultiViews".

--
Mark.
http://tranchant.plus.com/

[George Lund]

In message <qK*********************@stones.force9.net>, Mark Tranchant
<ma**@tranchant.plus.com> writes

Primarily bragging rights at this juncture. There are some advantages
to XHTML-1.1 though:
Fair play but you're not going to be let off the other reasons you give
all the same ;-) ...
1) Automatic validation in Mozilla and Firefox browsers, which will
throw an error message if the document is not well-formed XML.
There are validators with more useful error messages and better batch
capability; the browser is a _user_ agent and such messages certainly
wouldn't be useful to _them_.
2) Easier programmatic conversion from valid XHTML to other XML
variants than with arbitrary valid HTML, although *my* HTML always uses
lower-case tags and attributes, quotes attributes and closes all tags
except empty one.

I've had success with SX <http://www.jclark.com/sp/sx.htm> on the
occasion I've had need to do it (HTML->XML). (I don't recall seeing
that tool mentioned here ever and when I needed it I was grateful for
it, so maybe this will help someone.)

--
George Lund

[Jukka K. Korpela]

Mark Tranchant <ma**@tranchant.plus.com> wrote:

My site now uses Apache MultiViews and some PHP code to determine
whether your browser can handle the application/xhtml+xml media type.

As we have discussed a few times, this will fail for the most common
browser, which happily claims to be able to handle literally everything
(and with no expressed preference for text/html over anything).

But what really puzzles me is _why_ people want to do this. What does
XHTML 1.1 win, in practical terms? If the only gain is the author's pride
in following The Latest Recommendation, the price is pretty high.
Wouldn't it be better to gamble only when there's a _possibility_ of
winning something?

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Mark Tranchant]

Jukka K. Korpela wrote:

My site now uses Apache MultiViews and some PHP code to determine
whether your browser can handle the application/xhtml+xml media type.
As we have discussed a few times, this will fail for the most common
browser, which happily claims to be able to handle literally everything
(and with no expressed preference for text/html over anything).

I've not seen this - my logs show several people using various versions of
IE traversing the site in such a way that is only possible by them being
served text/html.

Indeed, a manual HTTP dialogue with my server reveals that an Accept header
of */* returns the HTML version.

If anyone has any evidence of *my* implementation failing for any browser,
I'd love to hear it.
But what really puzzles me is _why_ people want to do this. What does
XHTML 1.1 win, in practical terms? If the only gain is the author's pride
in following The Latest Recommendation, the price is pretty high.
But... it's what the W3C recommends! ;-)
Wouldn't it be better to gamble only when there's a _possibility_ of
winning something?

Yeah, I know the arguments. I like the elegance of having my documents
being well-formed XML, and the level of future-proofing that gives me. I
have no evidence for this, but I'd imagine the XHTML gives browsers an
easier time rendering the document.

--
Mark.
http://tranchant.plus.com/

[Nick Kew]

In article <ZJ**************@lund.co.uk>,
George Lund <ge****@lund.co.uk> writes:

I've had success with SX <http://www.jclark.com/sp/sx.htm> on the
occasion I've had need to do it (HTML->XML). (I don't recall seeing
that tool mentioned here ever and when I needed it I was grateful for
it, so maybe this will help someone.)

A good recommendation, but now rather dated. The SP project (of which
SX is one tool) has become OpenSP and lives at openjade.sourceforge.net.

--
Nick Kew

Nick's manifesto: http://www.htmlhelp.com/~nick/

[Bertilo Wennergren]

Mark Tranchant:

Jukka K. Korpela wrote:

But what really puzzles me is _why_ people want to do this. What does
XHTML 1.1 win, in practical terms? If the only gain is the author's pride
in following The Latest Recommendation, the price is pretty high.

But... it's what the W3C recommends! ;-)

Wouldn't it be better to gamble only when there's a _possibility_ of
winning something?

Yeah, I know the arguments. I like the elegance of having my documents
being well-formed XML, and the level of future-proofing that gives me. I
have no evidence for this, but I'd imagine the XHTML gives browsers an
easier time rendering the document.

Hardly (now). In most every practical case, the only real reason for
using XHTML (1.0 or 1.1) today, is if the page author/maintainer is more
comfortable with coding in that version. That goes for me for example,
and it seems to go for you too ("I like the elegance..."). For the users
it won't do any good (nor any harm, as far as I know).

In a couple of years, things might be different.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

[Jukka K. Korpela]

Mark Tranchant <ma**@tranchant.plus.com> wrote:

Jukka K. Korpela wrote:

My site now uses Apache MultiViews and some PHP code to determine
whether your browser can handle the application/xhtml+xml media
type.
As we have discussed a few times, this will fail for the most common
browser, which happily claims to be able to handle literally
everything (and with no expressed preference for text/html over
anything).

I've not seen this - my logs show several people using various
versions of IE traversing the site in such a way that is only
possible by them being served text/html.

Then your server does not work as you described. IE clearly says that it
can handle any data type.
Indeed, a manual HTTP dialogue with my server reveals that an Accept
header of */* returns the HTML version.
Then it doesn't do what you described. Simple as that. Surely */* covers
application/xhtml+xml just as well as text/html.
I like the elegance of having my
documents being well-formed XML,
Well-formedness is so extremely trivial that I think you are very happy
if you find happiness in such things. :-)
and the level of future-proofing that gives me.
There is no evidence suggesting that any future recommendation on HTML
would be compatible with XHTML 1.0 or XHTML 1.1. On the contrary, the
XHTML 2.0 draft is intentionally incompatible.
I have no evidence for this, but I'd imagine the XHTML
gives browsers an easier time rendering the document.

It surely doesn't. They have rendered old HTML for years, and XHTML
imposes further requirements.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Mark Tranchant]

Jukka K. Korpela wrote:

Mark Tranchant <ma**@tranchant.plus.com> wrote:

Jukka K. Korpela wrote:

As we have discussed a few times, this will fail for the most common
browser, which happily claims to be able to handle literally
everything (and with no expressed preference for text/html over
anything).

I've not seen this - my logs show several people using various
versions of IE traversing the site in such a way that is only
possible by them being served text/html.

Then your server does not work as you described. IE clearly says that it
can handle any data type.

Indeed, a manual HTTP dialogue with my server reveals that an Accept
header of */* returns the HTML version.

Then it doesn't do what you described. Simple as that. Surely */* covers
application/xhtml+xml just as well as text/html.

OK, I looked into why Apache consistently returns the text/html version.
The algorithm is detailed at:

http://httpd.apache.org/docs-2.0/con...html#algorithm

Only step 9 applies to my implementation - as the two variants are symlinks
to the same file, and the PHP isn't processed until after selection, the
content length appears the same to the selection algorithm.

It appears as though I've selected text/html as the default choice in
ambiguous situations through the good fortune of picking the correct
filename extensions... ;-)

I'll update my document when I can find the time.

I like the elegance of having my
documents being well-formed XML,

Well-formedness is so extremely trivial that I think you are very happy
if you find happiness in such things. :-)

I am a bear of very little brain.

and the level of future-proofing that gives me.

There is no evidence suggesting that any future recommendation on HTML
would be compatible with XHTML 1.0 or XHTML 1.1. On the contrary, the
XHTML 2.0 draft is intentionally incompatible.

Indeed, but I think it's clear that near-future recommendations will have
to be valid, well-formed XML as well. It's good to get into the right
habits, IMO.

I have no evidence for this, but I'd imagine the XHTML
gives browsers an easier time rendering the document.

It surely doesn't. They have rendered old HTML for years, and XHTML
imposes further requirements.

I think there is an advantage for Gecko-based browsers when served
application/xhtml+xml. They assume that the document is well-formed XML,
and kick up an error message if it isn't. The code to do this does not have
to deal with implicit element closing.

--
Mark.
http://tranchant.plus.com/

[Ashmodai]

Mark Tranchant scribbled something along the lines of:

David Dorward wrote:

Mark Tranchant wrote:

Primarily bragging rights at this juncture. There are some advantages to
XHTML-1.1 though:

1) Automatic validation in Mozilla and Firefox browsers, which will
throw
an error message if the document is not well-formed XML.

It will only check the XML for well formedness, it won't check the XHTML
itself.

I knew this would happen the instant I pressed Send on the original.
You're quite right, I should have written "Automatic validation of XML
well-formedness".

And you also should have avoided the term "validation" because
validation means checking conformance with a DTD.

--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Ashmodai]

George Lund scribbled something along the lines of:

In message <qK*********************@stones.force9.net>, Mark Tranchant
<ma**@tranchant.plus.com> writes

Primarily bragging rights at this juncture. There are some advantages
to XHTML-1.1 though:

Fair play but you're not going to be let off the other reasons you give
all the same ;-) ...

1) Automatic validation in Mozilla and Firefox browsers, which will
throw an error message if the document is not well-formed XML.

There are validators with more useful error messages and better batch
capability; the browser is a _user_ agent and such messages certainly
wouldn't be useful to _them_.

I think his point is that HE instantly knows when he made a mistake.
With HTML you would just sit there wondering why your page doesn't work
when you accidently have an unclosed element or a closing tag for a
non-existant one.

--
Alan Plum, WAD/WD, Mushroom Cloud Productions
http://www.mushroom-cloud.com/

[Mark Tranchant]

Ashmodai wrote:

Mark Tranchant scribbled something along the lines of:

I knew this would happen the instant I pressed Send on the original.
You're quite right, I should have written "Automatic validation of XML
well-formedness".

And you also should have avoided the term "validation" because
validation means checking conformance with a DTD.

Maybe I should have avoided the term "validation" because of the ensuing
arguments, but the word validation merely refers to the action of making or
checking validity.

Perhaps "verification" would have stopped all this pettiness, but then this
is ciwah... ;-)

--
Mark.
http://tranchant.plus.com/