Re: XHTML 1.0, section C14

On 21 Nov, Shane McCarron wrote:

> And please, let's not devolve into a discussion about content 
> negotiation.  The method above works.  Does it suck?  Sure.  Are there 
> browsers that lie in their request headers?  I surely hope not, but if 
> there are.... they deserve what they get.


  The guesstimated 75% IE 5, 6 and 7 users deserve to get XHTML served
  as XHTML it doesn't support?

  Sorry, Shane. The method you mention simply doesn't work out there;
  not for a majority of users. Developers have four options today:

   * Send XHTML as if it was HTML. This is frankly pointless; nothing is
     gained, even if nothing /much/ is lost.

   * Believe in the Accept header, and make life very, very difficult
     for a alot of people.

   * Believe in the Accept header /unless/ it is IE. Browser sniffing
     has never been viable.

   * Send HTML 4.01 which, for the majority of authors even in 2006, is
     more than enough for most purposes.

  Yes. There is something wrong with IE's Accept-header. It is wrong
  enough that it becomes very, very difficult to actually deploy
  content-negotiation in the real world. Which is a shame, but there you
  go.

  In an ideal world you would look at the Accept header, study the
  q-parameters, and decide on the best content to return[1]. The method is
  neat, and useful, and doesn't suck in the least. But in the real world
  we /don't/ do this, since most of us rather would like to avoid making
  sites inaccessible to the vast majority of users.

  We can do that by accepting that as long as we follow the informative
  appendix C, which is rather normative if we want to use text/html, or
  so the media-type note tells us, we can send XHTML.

  Or, since that takes all the "fun" out of XML, we can use HTML 4.01.



> If your document is written in XHTML 1.0 and follows the guidelines in Appendix C, you 
> can do this with the same document and you will be largely successful.  
> In fact, and without any evidence to back this up, I would bet that such 
> a document is almost exactly as likely to render correctly as if you 
> sent it with the HTML 4.01 DOCTYPE.

  Yes, well, the problem is rather what happens if you trust the Accept
  header and sends it as application/xml+xhtml.

  That won't render /at all/ in some UAs that claim to support it, with
  "it" being everything (*/*). If you send XHTML as text/html, then we
  are into tag-soup-ish territory anyway; regardless of DOCTYPE and
  compatibility.

  Appendix C add rules to avoid running head first into problems that
  might occur when attempting to parse XML with an HTML parser. This is
  rather equivalent to certain tricks used in HTML to achieve certain
  effects in certain browsers.


  While Mr. Hawkes-Lewis has presented a reasonable compromise, ultimately
  Mr. Korpela is correct:

   "Please don't use XHTML as the format of your web pages yet."


  Personally I think him too generous with his 'yet's.




 [1]
  Of course, then you'd run into this: http://www.mozilla.org/docs/web-developer/faq.html#accept
  which increase the pain. Mozilla's Accept-header claim application/xhtml+xml as q=1,
  text/html as q=0.9, and their developer documentation says "nevermind that".

  Mozilla, according to Mozilla, is better at handling HTML than XHTML.
  One would, then, assume they'd reversed those two q-values above. It
  doesn't do much for the viability of content-negotiation.

  But it was a good idea. So was User-Agent. Once.

-- 
 -       Tina Holmboe                           Greytower Technologies
       tina@greytower.net                      http://www.greytower.net
        +46 708 557 905

Received on Wednesday, 22 November 2006 16:08:58 UTC