- From: Sam Ruby <rubys@intertwingly.net>
- Date: Thu, 28 May 2009 09:41:36 -0400
- To: Anne van Kesteren <annevk@opera.com>
- CC: Maciej Stachowiak <mjs@apple.com>, "Roy T. Fielding" <fielding@gbiv.com>, Larry Masinter <masinter@adobe.com>, HTML WG <public-html@w3.org>
Anne van Kesteren wrote: > On Thu, 28 May 2009 15:15:11 +0200, Sam Ruby <rubys@intertwingly.net> > wrote: >> A concrete example is feed sniffing, where the operational behavior >> of feed readers is very different than the operational behavior of >> browsers. If this section is eventually split out, then the issue >> (with respect to "HTML 5: A vocabulary and associated APIs for HTML >> and XHTML") goes away. If, however, it ends up remaining, it needs >> to be identified clearly as operational behavior of one type of >> application, and not part of the vocabulary and associated APIs >> that all applications need to implement. > > Why would feed readers not need to implement that section if they > want to claim conformance with HTTP and still be compatible with > legacy content? I don't understand the "conformance with HTTP" part of the question. I believe that the current spec'ed behavior constitutes "a willful violation of the HTTP specification, which requires that the Content-Type headers be honored, despite implementation experience showing that this is not pratical in many cases.", though I believe that that note is not properly placed in the document, and misspells practical. The actual observed behavior of user agents designed to (primarily) process content of a certain media type (either in general, or in the specific context) is to make every effort to parse the content according to those rules, and only if such rules fail to produce meaningful results will they investigate alternatives. Browsers will first attempt to process content as HTML. FeedReaders will first attempt to process content as a feed. Media plays will first attempt to process content as media. Browsers, when chasing an image tag, will make different assumptions than when presented with a raw uri from the chrome. All are equally "right" or "wrong". None of this is meant to imply that the behavior that is being settled upon by browser manufacturers isn't worth specifying or standardizing. - Sam Ruby
Received on Thursday, 28 May 2009 13:42:09 UTC