Test pages served as html, xhtml, and xml

cwdjrxyz · Jan 18, 2006

To show how the same page(except for the text) is served with the
correct application/html, application/xml, and application/xhtml+xml
mime types installed on the server for the extensions .html, .xml, and
..xhtml, I have prepared four test pages at
http://www.cwdjr.info/extensions/ . Ignore the mime file in this
directory. The auto file uses a php include to select the correct mime
type for a browser. The text on the pages explains some of the
comparisons you might like to make. To best make this comparison, you
need at least a recent Mozilla family
browser(Firefox,Mozilla,Netscape), Opera, and IE6. These 3 classes of
browsers should show all of the differences mentioned in the text.

dorayme · Jan 18, 2006

cwdjrxyz said:
http://www.cwdjr.info/extensions/

Going to your http://www.cwdjr.info/extensions/auto.php on my
latest Safari, I get this insult:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>

But better, is it better?, in latest Mozilla for Mac OS X, I get:

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

I think this world is getting too complicated for a simple
Martian like me. Shall I complain bitterly in Mac groups about
this re Safari?

Hey, MP, did you see those dangerous bs, the safricans, in the
one-dayer the other day? They played with us like a cat with a
mouse, and then just squashed us. There will be a reckoning,
trust me.

cwdjrxyz · Jan 18, 2006

dorayme wrote:

I think this world is getting too complicated for a simple
Martian like me. Shall I complain bitterly in Mac groups about
this re Safari?

Hey, MP, did you see those dangerous bs, the safricans, in the
one-dayer the other day? They played with us like a cat with a
mouse, and then just squashed us. There will be a reckoning,
trust me.

Thanks for your observation. I knew Safari likely would work on the
auto page, because someone else once sent me a screen capture for
another page that used the same php include. However I did not know
what path it took. So far as I know, I can not install Safari on my
Windows XP OS for testing. I do know that many Apple computer owners
like their computer very much, especially those working with media.
Many Hollywood media types would have nothing but an Apple for their
work.

As the IE6 does not support true xhtml served properly and apparently
neither will the upcoming IE7, you have nothing to fear for your
Safari. You can start to worry when IE supports true xhtml and xhtml
takes off on many sites, if it ever does.

Toby Inkster · Jan 18, 2006

cwdjrxyz said:
As the IE6 does not support true xhtml served properly and apparently
neither will the upcoming IE7, you have nothing to fear for your
Safari. You can start to worry when IE supports true xhtml and xhtml
takes off on many sites, if it ever does.

Safari has good support XHTML support, and has done since it was in beta
testing.

cwdjrxyz · Jan 18, 2006

Toby said:
Safari has good support XHTML support, and has done since it was in beta
testing.

I was under the impression that Safari would support xhtml also until I
received the answer that it was being sent the html 4.01 strict version
when using the auto page.. Unfortunately, I can not download Safari to
my Windows XP for testing. At least for the auto select page, the
Sarfari got the xhtml 4.01 version of the page which it can handle. The
critical question is did the Safari accept the page served as true
xhtml 1.1 using the extension/ mime pairs on the server of .xhtml
application/xhtml+xml and .xml application/xml. Of course pages on the
web with these mime type/extension pairs are still rather rare, and
many likely never have downloaded such a page before. However, for the
main xhtml aware browsers such as Opera, Firefox, Netscape, and
Mozilla, all of the pages are handled just as they should be.

A lady who has Konqueror sent me an email. She gets the html 4.01 code
from the auto select page. However her worry was that her browser
supports xml. Since this could confuse some, I will snip a portion of
my answer to her below.

Thanks very much for your feedback. I believe that your browser does
not support a page served with the mime types application/xml or
application/xhtml+xml. However it supports serving as application/html.
These various methods do not mean a browser can not handle xml code if
it is written in a proper manner for a browser. For example, IE6 will
only accept a page served with the mime type application/html. However
you can use xml code on it if coded in a way that IE6 likes. You likely
have never noticed problems in displaying xml because nearly all
present web pages are served as application/html. Just because you
write a page in xhtml 1.1 does not mean it will be served as true
xhtml. That will only happen if you put pairs of extensions and mime
types on your server such as .xhtml application/xhtml+xml. If you use
an extension .html for the xhtml 1.1 page, it just gets served as
application/xhtml.

cwdjrxyz · Jan 19, 2006

cwdjrxyz said:
I was under the impression that Safari would support xhtml also until I
received the answer that it was being sent the html 4.01 strict version
when using the auto page.. Unfortunately, I can not download Safari to
my Windows XP for testing. At least for the auto select page, the
Sarfari got the xhtml 4.01 version of the page which it can handle. The
critical question is did the Safari accept the page served as true
xhtml 1.1 using the extension/ mime pairs on the server of .xhtml
application/xhtml+xml and .xml application/xml. Of course pages on the
web with these mime type/extension pairs are still rather rare, and
many likely never have downloaded such a page before. However, for the
main xhtml aware browsers such as Opera, Firefox, Netscape, and
Mozilla, all of the pages are handled just as they should be.

A lady who has Konqueror sent me an email. She gets the html 4.01 code
from the auto select page. However her worry was that her browser
supports xml. Since this could confuse some, I will snip a portion of
my answer to her below.

Thanks very much for your feedback. I believe that your browser does
not support a page served with the mime types application/xml or
application/xhtml+xml. However it supports serving as application/html.
These various methods do not mean a browser can not handle xml code if
it is written in a proper manner for a browser. For example, IE6 will
only accept a page served with the mime type application/html. However
you can use xml code on it if coded in a way that IE6 likes. You likely
have never noticed problems in displaying xml because nearly all
present web pages are served as application/html. Just because you
write a page in xhtml 1.1 does not mean it will be served as true
xhtml. That will only happen if you put pairs of extensions and mime
types on your server such as .xhtml application/xhtml+xml. If you use
an extension .html for the xhtml 1.1 page, it just gets served as
application/xhtml.

I examined the php include in the auto page that processes the header
information. It is set up to use the true xhtml page only if it finds
the mime type application/xhtml+html mentioned by the browser as a
possible application when the server and browser first connect. If no
mention of this mime type is found, it takes the safe "else" path to
serve as html 4.01 strict, since anything else would require elaborate
browser and version detection that is far from safe. It is quite
posible a browser vendor could make an "xhtml ready" browser. That is,
it would handle xhtml served as html(which is no big deal), but it
could accept true xhtml served as such at some future time when the
browser vendor thinks the browser is ready and adds the correct mime
type for it in the header information the browser provides the server.
Such a "xhtml ready" browser might or might not support a page served
only as application/xhtml+xml or as application/xml. It might be
possible to hack around this if there really are any "xhtml ready"
browsers. However I can not afford to add extra computers to support
some of the browsers of interest, these browsers are not used very much
yet, and there would be many possible problems in detecting which
browser and version you had. Thus I am content to let any possible
"xhtml ready" browers receive xhtml 4.01 strict for now.

cwdjrxyz · Jan 19, 2006

cwdjrxyz said:
I examined the php include in the auto page that processes the header
information. It is set up to use the true xhtml page only if it finds
the mime type application/xhtml+html mentioned by the browser as a
possible application when the server and browser first connect. If no
mention of this mime type is found, it takes the safe "else" path to
serve as html 4.01 strict, since anything else would require elaborate
browser and version detection that is far from safe. It is quite
posible a browser vendor could make an "xhtml ready" browser. That is,
it would handle xhtml served as html(which is no big deal), but it
could accept true xhtml served as such at some future time when the
browser vendor thinks the browser is ready and adds the correct mime
type for it in the header information the browser provides the server.
Such a "xhtml ready" browser might or might not support a page served
only as application/xhtml+xml or as application/xml. It might be
possible to hack around this if there really are any "xhtml ready"
browsers. However I can not afford to add extra computers to support
some of the browsers of interest, these browsers are not used very much
yet, and there would be many possible problems in detecting which
browser and version you had. Thus I am content to let any possible
"xhtml ready" browers receive xhtml 4.01 strict for now.

I have added another page named
http://www.cwdjr.info/extensions/autoForceXhtml.php .
It is designed to automatically force the page to be served as
application/xhtml+xml no matter what the browser says it will support
or likes in the header exchange. Thus browsers that really will not
support true xhtml 1.1 served properly will not display the page.
However if there is a "xhtml ready" browser out there that really could
support true xhtml, but does not because it does not mention it in the
browser-server header exchange, this page may smoke it out. I give more
discussion on the page if your browser allows you in. This new page
gets in and displays for the recent Firefox, Netscape, Mozilla, Opera,
and W3C Amaya browsers. It does not open the page for IE6 or Netscape
4.8, which of course it should not. Of course I do not know if there
are really any "xhtml ready" browsers out there, and if there are I do
not have them installed on my computer.

Toby Inkster · Jan 19, 2006

cwdjrxyz said:
I was under the impression that Safari would support xhtml also until I
received the answer that it was being sent the html 4.01 strict version
when using the auto page.

Just because it's being *sent* HTML in your example, that doesn't mean
that it doesn't *support* XHTML -- it just means that you're not sending
XHTML to it (for whatever reason).

Chaddy2222 · Jan 19, 2006

cwdjrxyz said:
I have added another page named
http://www.cwdjr.info/extensions/autoForceXhtml.php .
It is designed to automatically force the page to be served as
application/xhtml+xml no matter what the browser says it will support
or likes in the header exchange. Thus browsers that really will not
support true xhtml 1.1 served properly will not display the page.
However if there is a "xhtml ready" browser out there that really could
support true xhtml, but does not because it does not mention it in the
browser-server header exchange, this page may smoke it out. I give more
discussion on the page if your browser allows you in. This new page
gets in and displays for the recent Firefox, Netscape, Mozilla, Opera,
and W3C Amaya browsers. It does not open the page for IE6 or Netscape
4.8, which of course it should not. Of course I do not know if there
are really any "xhtml ready" browsers out there, and if there are I do
not have them installed on my computer.

Well, your forced XHTML page seams to work fine in FireFox1.0.7, but
not in IE as you expected.
As a thaught, if you want to serve HTML in stead of XHTML, I would just
serve HTML4.01Strict too both browsers as it is a lot less work and may
save a lot of problems when rendering between, say IE7 and previous
versions of Ie. I also think that useing XHTML at the moment is a bit
pointless, as not even some PDA's support it.

dorayme · Jan 19, 2006

cwdjrxyz said:
http://www.cwdjr.info/extensions/autoForceXhtml.php

This link displays in Mac browsers: Safari, the latest Mozilla
(for X) and latest Opera (for X) in the source:

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

while in the browser, your message (in white on blue):

This page is automatically forced to be served as
applicatiom/xhtml+xml no matter what the browser says it supports
are likes to support. Thus any browser that really will not
support true xhtml 1.1 properly served will not display the page.
A browser that is completely "xhtml ready" that really could
serve true xhtml but usually will not because it does not mention
application/xhtml +xml support in the header exchange between it
and the server may be smoked out by this approach. I would
greatly appreciate knowing if anyone finds a browser that gives
you only a html 4.01 strict page when you use the auto page and
gives you an xhtml 1.1 page when you use this page.

cwdjrxyz · Jan 19, 2006

Toby said:
Safari has good support XHTML support, and has done since it was in beta
testing.

I think that Dorayme, in his latest post, may have provided the answer
for Safari. It can be forced to go the true xhtml route if one does
that in the header/server exchange and allows no other options. This is
nearly, but not absolute, evidence that Safari does not provide the
mime type application/xhtml+xml as an option, since it takes the 4.01
route using the auto page and many other browsers will take the true
xhtml route if offered at all by the browser by the header/server
exchange. If I had a Safari browser, I could write many test php header
programs to run down all of the details, but I do not. Whatever the
reason that Safari responds the way it does, at least no harm will be
done if it gets a page as html 4.01 strict rather than true xhtml 1.1.
If, on the other hand, a browser that can not handle xhtml 1.1 got a
page written in it, this would be a problem. In theory, detection of
the Safari browser and version number could be used to force true xhtml
for Safari. However, in these days when browsers spoof one another,
detection of browser name and version has fallen into disfavor - many
have locked out some browsers by using it.

cwdjrxyz · Jan 19, 2006

dorayme said:
This link displays in Mac browsers: Safari, the latest Mozilla
(for X) and latest Opera (for X) in the source:

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

while in the browser, your message (in white on blue):

This page is automatically forced to be served as
applicatiom/xhtml+xml no matter what the browser says it supports
are likes to support. Thus any browser that really will not
support true xhtml 1.1 properly served will not display the page.
A browser that is completely "xhtml ready" that really could
serve true xhtml but usually will not because it does not mention
application/xhtml +xml support in the header exchange between it
and the server may be smoked out by this approach. I would
greatly appreciate knowing if anyone finds a browser that gives
you only a html 4.01 strict page when you use the auto page and
gives you an xhtml 1.1 page when you use this page.

Thanks again. This is nearly, but not absolute, evidence that Safari
does not provide the mime type application/xhtml+xml as an option,
since it takes the 4.01 route using the auto page and many other
browsers will take the true xhtml route if offered at all by the
browser by the header/server exchange. If I had a Safari browser, I
could write many test php header programs to run down all of the
details, but I do not. Whatever the reason that Safari responds the way
it does, at least no harm will be done if it gets a page as html 4.01
strict rather than true xhtml 1.1

cwdjrxyz · Jan 19, 2006

cwdjrxyz said:
Thanks again. This is nearly, but not absolute, evidence that Safari
does not provide the mime type application/xhtml+xml as an option,
since it takes the 4.01 route using the auto page and many other
browsers will take the true xhtml route if offered at all by the
browser by the header/server exchange. If I had a Safari browser, I
could write many test php header programs to run down all of the
details, but I do not. Whatever the reason that Safari responds the way
it does, at least no harm will be done if it gets a page as html 4.01
strict rather than true xhtml 1.1

There is a chance that Safari might say that it supports
application/xml and not say that it supports application/xhtml+xml.
This would be an acceptable method to support xhtml, but I have never
seen it used by a browser before. Anyway, I have a new auto page at
http://www.cwdjr.info/extensions/autoWithXML.php . This checks to see
if the browser offers either application/xhtml+xml support or
application/xml support. If it does you get an xhtml 1.1 page. Else you
get an html 4.01 strict page. This page displays as xhtml 1.1 on Opera,
Mozilla, Netscape, Firefox, and the W3C Amaya browsers. It displays as
html 4.01 strict on the IE6 and Netscape 4.8, as it should. It would be
interesting to see what Safari does. I would be very surprised if
Sarfari would say that it supports application/xml rather than
application/xhtml+xml, but Apple could have gone avant-garde and become
one of the first browsers on the block to do this.

Toby Inkster · Jan 19, 2006

cwdjrxyz said:
I think that Dorayme, in his latest post, may have provided the answer
for Safari. It can be forced to go the true xhtml route if one does
that in the header/server exchange and allows no other options. This is
nearly, but not absolute, evidence that Safari does not provide the
mime type application/xhtml+xml as an option

Safari's HTTP Accept header is as follows:

Accept: */*

which leaves it open for pretty much anything!

(Testing Safari 1.3.1.)

cwdjrxyz · Jan 19, 2006

Toby said:
Safari's HTTP Accept header is as follows:

Accept: */*

which leaves it open for pretty much anything!

(Testing Safari 1.3.1.)

Thanks very much Toby. That is consistent with the results obtained for
Safari for the original auto page that uses 4.01 strict if
application/xhtml+xml support is not mentioned by the browser in the
browser/server header exchange and the fact that the Safari could be
forced to accept application/xhtml+xml if no other option is given in
the php include. I hope that I hear from the lady with the Konqueror
again to see if it could be forced to accept application/xhtml+xml.
This leaves the safe option of letting Safari receive html 4.01 strict.
I may look at how difficult and reliable it is to detect Safari, but
this approach is so risky that I am going to be in no hurry to do so. I
doubt if many people, except on a Network where everything can be
controlled, are going to be serving true xhtml to Safari because, to
serve it as application xhtml+xml only, would make the page unusable on
IE6 an some other browsers.

Toby Inkster · Jan 20, 2006

cwdjrxyz said:
Thanks very much Toby. That is consistent with the results obtained for
Safari for the original auto page that uses 4.01 strict if
application/xhtml+xml support is not mentioned by the browser

It doesn't mention text/html support either, so why send HTML in
preference to XHTML?

I hope that I hear from the lady with the Konqueror again to see if it
could be forced to accept application/xhtml+xml.

Konqueror supports XHTML served as application/xhtml+xml just fine. The
HTTP Accept header (for Konq 3.1.4) is:

Accept: text/html, image/jpeg, image/png, text/*, image/*, */*

dorayme · Jan 20, 2006

Toby Inkster said:
Safari's HTTP Accept header is as follows:

Accept: */*

which leaves it open for pretty much anything!

(Testing Safari 1.3.1.)

I was using 2.0.3 (also the other Mac browsers I mentioned were
the latest)

cwdjrxyz · Jan 20, 2006

Toby said:
Konqueror supports XHTML served as application/xhtml+xml just fine. The
HTTP Accept header (for Konq 3.1.4) is:

Accept: text/html, image/jpeg, image/png, text/*, image/*, */*

I am indebted to you again, Toby, for the above Accept information for
Konqueror. Since it does not mention application/xhtml+xml in the
Accept header information, it would be expected to route my auto page
for the html 4.01 strict version. This is just what the lady who sent
me an email found. Fortunately this is the safe thing to do. As for the
Apple Safari, you would have to serve the page as proper xhtml 1.1 to
get it to respond as xhtml 1.1. However, as with the Safari, not many
people will want to do this, except on a controlled network, because
such a page would not be seen on IE6, for example. Getting around this
likely would require risky browser name and version detection.

=?ISO-8859-1?Q?G=E9rard_Talbot?= · Jan 20, 2006

cwdjrxyz wrote :

I have prepared four test pages at

http://www.cwdjr.info/extensions/ .

When I load the page
http://www.cwdjr.info/extensions/xhtml11.xhtml
with Firefox 1.5, I can read this
"There is no correction for a background-color style sheet problem on
Mozilla family browsers that was corrected on the auto php page."
But, like I wrote you in the other thread (XHTML or HTML 4), this is not
correct:

"The background of the root element becomes the background of the canvas
and covers the entire canvas, anchored at the same point as it would be
if it was painted only for the root element itself. The root element
does not paint this background again.

For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element. For HTML
documents whose root HTML element has computed values of 'transparent'
for 'background-color' and 'none' for 'background-image', user agents
must instead use the computed value of those properties from that HTML
element's first BODY element child when painting backgrounds for the
canvas, and must not paint a background for that BODY element. This does
not apply to XHTML documents. "
CSS 2.1, Section 14.2 The background
http://www.w3.org/TR/CSS21/colors.html#q2

Reported bug at Opera, bug 176629

XHTML body background propagates to canvas
http://geocities.com/csssite/operabugs/bug53.xhtml

https://bugzilla.mozilla.org/show_bug.cgi?id=147436
https://bugzilla.mozilla.org/show_bug.cgi?id=272804

Gérard

cwdjrxyz · Jan 20, 2006

Gérard Talbot said:
cwdjrxyz wrote :

I have prepared four test pages at

When I load the page
http://www.cwdjr.info/extensions/xhtml11.xhtml
with Firefox 1.5, I can read this
"There is no correction for a background-color style sheet problem on
Mozilla family browsers that was corrected on the auto php page."
But, like I wrote you in the other thread (XHTML or HTML 4), this is not
correct:

"The background of the root element becomes the background of the canvas
and covers the entire canvas, anchored at the same point as it would be
if it was painted only for the root element itself. The root element
does not paint this background again.

From a strict technical standpoint, apparently Mozilla family browsers

are meeting the specifications. However, from a practical standpoint, I
think Opera may have done the best thing. I suppose a good lawyer could
argue that Opera meets the background coverage required by the
specifications and also exceeds it. All of this may be of minor
practical importance in many cases. The point is that you are going to
have to write background color code in a different way for an xhtml
page as long as Opera and Mozilla family browsers implement the
background color in a different way and you want the page to appear
about the same on the various browsers. This mainly becomes a problem
when you have a short page that does not fill the screen and use a dark
colored background, if you do not like the glare of a bright screen
below the page content. For a page that exceeds the height of the
screen greatly, or for light backgrounds, the glare of the bright
screen below the content is not nearly as bothersome. Anyway this is
the least of my concerns at the moment in an attempt to get as many
recent browsers as possible to be served as true xhtml 1.1. However,
thanks for the references, as I might want to look into the details
more when I am more concerned with actual writing of code in xhtml 1.1
.. My general impression is that I like the way Opera supports xhtml 1.1
a bit better than how the Mozilla family browsers do. One can no doubt
find many small deviations from strict specifations for both Opera and
Mozilla family browsers, viewed in the most literal light. After all,
there still are many deviations from specifications for html,
especially in IE6. It is difficult to strike the best balance between
being too literal and too loose. I believe it may have been Lord
Chesterfield that made an observation to the effect that a gentleman is
one who knows the rules before breaking them

.

IE9 beta finally seems to support xhtml properly	2	Sep 24, 2010
XHTML and HTML	14	Jun 12, 2007
XML/XHTML/HTML differences, bugs... and howto	0	Jan 23, 2013
Solving script and other problems for serving true xhtml 1.1	1	Aug 27, 2005
Test of video in xtml5	0	Jul 11, 2010
XHTML & application/xml?	3	Jan 23, 2009
XHTML replaced by XML ?	4	Nov 1, 2006
ie xhtml rendering with script code	1	Feb 25, 2011

Test pages served as html, xhtml, and xml

cwdjrxyz

dorayme

cwdjrxyz

Toby Inkster

cwdjrxyz

cwdjrxyz

cwdjrxyz

Toby Inkster

Chaddy2222

dorayme

cwdjrxyz

cwdjrxyz

cwdjrxyz

Toby Inkster

cwdjrxyz

Toby Inkster

dorayme

cwdjrxyz

=?ISO-8859-1?Q?G=E9rard_Talbot?=

cwdjrxyz

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads