109837 - renders pages with XHTML doctype but text/html MIME type in quirks mode

Status: RESOLVED INVALID

(Core :: XML, defect)

Description

[Damian Yerrick]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.5+) Gecko/20011108
BuildID:    2001110803

Some web designers may want to use XHTML, but their hosting provider
does not let them set .xml documents as MIME type text/xml or does
not let them create server-parsed XHTML.  Mozilla fails to recognize
the doctype of a Valid XHTML 1.0 Transitional  page served as text/html
as a valid HTML doctype and renders the page in quirks mode instead of
standard mode.

Reproducible: Always
Steps to Reproduce:
1. Connect to the Internet over a slow (<= 56K) connection.
2. Start Mozilla.
3. Visit http://pineight.evilpigeon.net/

Actual Results:
Little smiley faces (or other broken image icons) appear under images
that have not loaded, letting me know that Mozilla renders the page in
quirks mode.

Expected Results:  No placeholders appear, and Mozilla renders the page
as XHTML, in standards mode, barfing on any well-formedness error.

This could potentially be an evangelism issue, but note that marking
a page as text/xml may cause problems viewing the page in other
browsers, and note further that not everybody can afford $10 per
month for CGI hosting that lets the designer set the Content-type.

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This is a dupe really, but I could not find it.

Mozilla will not do content sniffing. We trust the mime type. Marking as WONTFIX.

XML is becoming more common on the web and there is no technical reason for web
hosting services to NOT add a mapping from .xml to text/xml etc. Bug your
ISP/hosting service. If they do not listen to you, gather everyone you know to
bitch. If that does not work, file an Evangelism bug on Mozilla for that ISP/web
hosting provider.

I know of at least one ISP that does not offer that for regular customer, only
corporate customers or people who pay for the premium service.

Comment 2

[Damian Yerrick]

Why exactly does Mozilla's HTML mode not treat XHTML doctype as equivalent to
HTML 4.01?

Could we make this bug (or the first report, if found) into a meta-bug for
such tech evangelism issues as they pop up?

Comment 3

[Chris Petersen]

Confirmed. 

Comment 4

[Damian Yerrick]

Now that we have a meta-bug, let's form our evang strategy for this type
of bug, so that we can refer the providers to this page or to another page
on mozilla.org.

In order for a hosting provider to be able to send text/xml, it would have to
do the following:
 * add MIME type mapping *.xml -> index/xml
 * add index.xml as a valid directory index
 * special case IE 5 and 6's XML handling (see below)

In addition, for server-parsed XML:
 * add MIME type mapping *.sxml -> index/xml
 * set up a server-parsed handler on .sxml
 * add index.sxml as a valid directory index
 * special case IE 5 and 6's XML handling (see below)

IE 5 and 6 handle XHTML documents served as text/xml incorrectly.  For
instance, going to http://yerricde2.student.rose-hulman.edu/test.sxml in IE 5
or 6  will view the XML source in collapsible tree form (which, by the way,
would be rather nice to have in Mozilla) rather than rendering the XHTML
document.  Other testers have been running into this problem:
  http://bugzilla.mozilla.org/show_bug.cgi?id=109445#c10

Yes I know this isn't strictly Mozilla's problem, but how should ISPs and
hosting  providers provide correct content to XHTML-compatible browsers
without making a mess in the browser that has 90% of the market share?

Or, based on IE's behavior, should someone revert this bug to the old status?
  Product: Browser
  Component: XML
  Summary: Renders XHTML pages sent as MIME type text/html in quirks mode

Or should I just work around this bug by sending all XHTML pages as HTML 4.01?

Comment 5

[Damian Yerrick]

Sorry for replying to my own comment, but I did a little more digging.

> Mozilla will not do content sniffing. We trust the mime type.

Incorrect behavior.  The XHTML 1.0 standard states that XHTML documents MAY
be labeled with MIME type text/html; in other words, documents labeled as
text/html MAY contain XHTML markup.  Quoting from the standard:

W3C> However, XHTML Documents which follow the guidelines set forth in
W3C> Appendix C, "HTML Compatibility Guidelines" may be labeled with the
W3C> Internet Media Type "text/html", as they are compatible with most HTML
W3C> browsers. This document makes no recommendation about MIME labeling of
W3C> other XHTML documents.

Thus, the MIME type text/html refers to HTML, not specifically SGHTML.
This makes a pretty strong case for sniffing the content of the document to
determine whether to handle it as SGHTML or as XHTML.  (Further discussion
at http://lists.w3.org/Archives/Public/www-html/2001Oct/0065.html)

Let's see...
 1. Hosting providers charge extra for text/xml MIME type
 2. IE cannot render XHTML documents sent as text/xml
 3. W3C states that XHTML documents MAY carry text/html MIME type

Reverting the bug.  Related bugs may include bug 107904 and bug 94284.
Fixing this would fix bug 109445.  If we can't make the parser switch to XML
mode, at least render the document as HTML 4.01 rather than quirks mode.

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I thought XHTML doctype in a document served as text/html will trigger 4.01
strict mode... If it doesn't it is a bug.

Damian, the part you quote from the spec says to me that if and only if an XHTML
document follows Appendix C (like using both id and name attributes on elements
to ensure backwards compatibility) it may be served with text/html. However, the
"if and only if" part is my interpretation and the mailinglist link clearly
shows other people are confused as well. I have no idea what you mean by SGHTML,
and I am not aware of index/xml mime type.

Comment 7

[Damian Yerrick]

> I thought XHTML doctype in a document served as text/html will trigger 4.01
> strict mode...

Or 4.01 transitional, depending on the XHTML doctype.

> If it doesn't it is a bug.

It doesn't.  Build 2001110803 (the latest reviewed by MZ) renders such pages
in quirks mode.  If it were rendering in standards mode (such as html4 loose
or html4 strict), I wouldn't have filed this bug.

> if and only if an XHTML document follows Appendix C (like using both id and
> name attributes on elements to ensure backwards compatibility) it may be
> served with text/html.

Right.  And I use those practices.  However, Mozilla currently renders XML
served as text/html in QUIRKS mode.

> not aware of index/xml mime type

OOPS! I meant text/xml.
<offtopic>
Most BBSes have either a preview button (Slashdot, Kuro5hin) or an edit posted
comment button (Everything) or both (some Wikis).  I was thinking of setting up
index.xml as a directory index, and one part of my brain got ahead of the other.
</offtopic>

I'll open another text/xml evange bug later, once IE fixes its text/xml bug
[like that's gonna happen ;-) ].
__________________________________________

To sum up:

Reproduce:
1. Go to any page with an XHTML doctype and text/html media type, such as
   http://pineight.evilpigeon.net/

Actual results:
Mozilla renders the page in quirks mode with placeholders.

Expected results:
Mozilla renders the page according to the HTML 4.01 standard.

Comment 8

[rbs]

dup: bug 67646

Comment 9

[Henri Sivonen (:hsivonen)]

I suggest this bug be resolved INVALID.

* Mozilla parses XHTML sent as text/html using the HTML parser. Mozilla uses the
standards layout mode. (Reporter, please check that your mode tests are correct.)
* The reporter is basically filing an IE bug in Bugzilla.
* The XHTML 1.0 spec says that XHTML 1.0 docs may be served as text/html in oder
to be comatible with old browsers. That is, the old browsers will parse as tag
soup anyway.
* We can't parse text/html docs that have the an XHTML doctype as XML, because
there are high-provile sites out there (eg. http://www.oreilly.com/) that use an
XHTML doctype bug serve ill-formed docs.
* Making the XML parser more lenient in order to deal with such pages would be
evil. The benefits of XML would be lost if XML degenerated into tag soup.
(More on this: http://www.hut.fi/u/hsivonen/xhtml-the-point)
* If you are using Apache, you can use content negotiation to serve the same doc
as text/xml to Mozilla (or any other brower that accepts it) and as text/html to
others. Live example: http://www.hut.fi/~hsivonen/test/xhtml-suite/xhtml-index
(sends XHTMl Basic as application/xhtml+xml or HTML 4.01 Strict as text/html--no
Perl or PHP involved, only a simple Apache .var file.)
* Why does Mozilla treat XHTML 1.0 sent as text/html equivalent to HTM 4.01?
Well, XHTML 1.0 is just a syntactic reformulation of HTML 4.01.

Sample .var file (assuming URL ending in "test"):
--------8<---------
URI: test

URI: test.xhtml
Content-type: application/xhtml+xml;q=0.95

URI: test.xml
Content-type: text/xml;q=0.95

URI: test.html
Content-type: text/html;q=1

Comment 10

[Damian Yerrick]

> Mozilla parses XHTML sent as text/html using the HTML parser. Mozilla uses
> the standards layout mode. (Reporter, please check that your mode tests are
> correct.)

Bug 52730 blocks checking that my mode tests are correct.  What is the easiest
way to determine whether Mozilla renders a given page in quirks or standard
mode before the bug 52730 patch gets r=, sr=, and checkin?

> filing an IE bug in Bugzilla.

I'm beginning to think I shouldn't have even adopted XHTML at all, let alone
filed this bug.  If anybody knows where to file IE bugs (don't just tell me
"not here" because I KNOW it's not here), please help me.  Starting from
http://www.microsoft.com/windows/ie/support/ produced nothing helpful.

> there are high-provile sites out there (eg. http://www.oreilly.com/)
> that use an XHTML doctype bug serve ill-formed docs.

Somebody should file a tech evangelism bug about that site.  Or has somebody?
Searching summaries for oreilly didn't produce anything useful.

> If you are using Apache, you can use content negotiation to serve the same doc

I did a Google search for "apache var file" as you suggested and found
  http://www.apacheweek.com/features/negotiation
Turns out the default installation of Apache HTTP Server does not support
content negotiation until the owner of the box (not necessarily the web
developer) uncomments a line.  Should this bug become an evangelism metabug
again now that we have a method that hosting providers can use to let their
customers do content negotiation, serving correct content to both Mozilla
and the competition?

Comment 11

[Henri Sivonen (:hsivonen)]

I'm marking this INVALID because
* The description is incorrect. XHTML documents are rendered in the standards
mode.
(http://www.bath.ac.uk/%7Epy8ieh/cgi/compat-test.pl?DOCTYPE=%3C%21DOCTYPE+html+PUBLIC+%22-%2F%2FW3C%2F%2FDTD+XHTML+1.0+Transitional%2F%2FEN%22+%22http%3A%2F%2Fwww.w3.org%2FTR%2Fxhtml1%2FDTD%2Fxhtml1-transitional.dtd%22%3E&MODE=full)
* When dbaron and Hixie asked the HTML WG about this, the WG said the HTML
parser should be used for text/html.
(http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html)

> What is the easiest way to determine whether Mozilla renders a 
> given page in quirks or standard

http://www.bath.ac.uk/%7Epy8ieh/cgi/compat-test.pl
(Don't pay attention to the parsing mode stuff. It is outdated.)

> If anybody knows where to file IE bugs (don't just tell me
> "not here" because I KNOW it's not here), please help me.

http://register.microsoft.com/mswish/suggestion.asp

> Should this bug become an evangelism metabug

No. This bug has so many non-evang comments that morphing the bug is no good.