On Sat, Sep 4, 2010 at 8:47 PM, Brandon S Allbery KF8NH
-----BEGIN PGP SIGNED MESSAGE----- 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" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <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. (http://www.dev-archive.net/articles/xhtml.html#types) 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: http://www.schillmania.com/content/entries/2004/10/24/application-xhtml+xml/... 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. (https://developer.mozilla.org/en/Gecko's_"Almost_Standards"_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@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyC9qsACgkQIn7hlCsL25U8uACfdDA4RLUv5LedObrIaO4DpQE1 0CMAnj5ntJ6dhRju5sCw7IGfor68Aaa4 =TaCL -----END PGP SIGNATURE----- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe