[Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

Jeremy Shaw jeremy at n-heptane.com
Sat Sep 4 22:35:47 EDT 2010

On Sat, Sep 4, 2010 at 8:47 PM, Brandon S Allbery KF8NH
<allbery at ece.cmu.edu> wrote:
> Hash: SHA1
> On 9/4/10 21:27 , Jeremy Shaw wrote:
>> Here is why I am dubious. Browsers that support html and xhtml have
>> two different code paths for rending html vs xhtml. The *only* way to
>> select which code path is taken is by specifying the mime-type when
>> you serve it. Either application/xml or text/html.
> XHTML starts with a <!DOCTYPE>.  You've just asserted that no browser is
> capable of noticing that and responding to it even though it's right at the
> start, while somehow managing to support <META HTTP-EQUIV=...> tags buried
> in the <HEAD> that can force it to go back and start from scratch.  Really?

Browsers *could* look at the doctype to pick the path. But they  *do
not*. What they look at is the http header that is sent before the
response body is even parsed. (Obviously, things are a little
different if it is reading a file from the disk).

For example, if you do, curl -v http://www.w3.org/, you will see this:

< Content-Type: text/html; charset=utf-8
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

Where the, Content-Type: text/html; charset=utf-8, is an HTTP response
header. Rather than second guess what the response body is, the
browsers consider that content-type header to be authoritative over
the <meta /> tag.

If you open that url in firefox, and go to, Tools > Page Info, it will tell you:

Type: text/html
Render Mode: Standards Compliance Mode
Encoding: utf-8

Meaning that even though it has the xhtml doctype (clearly shown in
the curl output), firefox is only paying attention to the text/html
content type.

If you visit this page, http://www.echoofeden.com/htmlTests/xhtmlFix/index.xhtml

Then it shows:

Type: application/xhtml+xml

Or, perhaps more relevant is this page:

Which contains an xml error. You can tell it is using the XML
rendering path, because it correctly gives an error instead of trying
to guess what you mean and rendering the page anyway.

Now, in the case of firefox. If you serve an xhtml with the DOCTYPE as
text/html, it will trigger the use of the text/html renderer. If the
DOCTYPE is xhtml 1.0 transition, then the browser will sniff that and
use 'almost standards' mode. Which is exactly like the normal
text/html standards mode except for one thing: the layout of images
inside table cells is handled as they are in Gecko's "quirks" mode.

Everything I have ever read says that browsers only look at the
content-type header to choose html vs xhtml rendering. And the
supporting evidence seems to indicate that is true. If you have
contrary evidence I would be glad to hear it. It's really difficult to
find reliable information on this topic.

- jeremy

>  Or have we all been imagining the latter for the past, oh, 15 or so years?
>  (Mozilla had a serious bug relating to that restart for years; I assure you
> it's not a fantasy.)
> I wouldn't be surprised if HTML and XHTML ultimately follow different
> rendering paths --- but your assertions are raising red flags and smell
> suspiciously like ideology taking offense at reality not automatically
> constraining itself to fit in its assigned pigeonhole.
> - --
> brandon s. allbery     [linux,solaris,freebsd,perl]      allbery at kf8nh.com
> system administrator  [openafs,heimdal,too many hats]  allbery at ece.cmu.edu
> electrical and computer engineering, carnegie mellon university      KF8NH
> Version: GnuPG v2.0.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 0CMAnj5ntJ6dhRju5sCw7IGfor68Aaa4
> =TaCL
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list