- From: Sam Ruby <rubys@intertwingly.net>
- Date: Wed, 05 Jan 2011 11:38:57 -0500
- To: Anne van Kesteren <annevk@opera.com>
- CC: public-html-xml@w3.org, Henri Sivonen <hsivonen@iki.fi>
On 01/05/2011 11:17 AM, Anne van Kesteren wrote: > On Wed, 05 Jan 2011 16:38:37 +0100, Sam Ruby <rubys@intertwingly.net> > wrote: >> I note that you don't define soon, all, or browsers. > > Since you mentioned you wanted to include feed readers, I was not sure > that would be relevant. Browsers I would include are those based on > Trident, Presto, WebKit, and Gecko. Soon would be in a couple of years. In two years, there will still be significant amount of IE8 deployed. >> Additionally, there are feed formats, such as RSS 2.0, which do not >> provide a means to clearly identify the mime type of descriptions. >> Until all user agents are rewritten "properly" and all legacy document >> formats are retired, I don't believe that use cases should be rejected >> based on how an ideal world would look like any more than I believe >> that HTML5 should ignore supporting the vast corpus of existing >> content as a requirement. > > I think these are different things. While HTML5 very much takes legacy > into account. Its design aspires an ideal world given the legacy > constraints. Certainly not two ways to process text/html. E.g. HTML5 > does not say you can parse legacy color values in these three different > ways. No, it defines one single way, and the test suite will make sure > it is implemented that way eventually. HTML5 is not alone in this, other > specifications dealing with legacy constraints are written using a > similar philosophy (CSS comes to mind). > > It seems you are arguing against this design philosophy. At least in part. I don't believe I'm arguing against this. To make this concrete: I'm arguing *FOR* producers of XHTML5 to use the self-closing syntax when emitting br elements and not to use the self-closing syntax when emitting script elements. I've never heard a satisfactory answer to the question as to why the spec is defined this way, but even if the spec were changed tomorrow, there will remain legacy user agents which work better if these constraints are followed. Instead attempting to putt words in my mouth, can you point out specifics? In particular, can you point out any specific instances on either my weblog and planet of a problem? >> There are many scenarios where consumers will have to sniff or guess >> content. Hopefully, over time, more will converge or default to HTML5 >> as the way to parse unknown or mislabeled content. Ideally, most >> content will degrade gracefully with this choice, even if the original >> author's intent was XHTML1.0 or XHTML5. In fact, this generally is the >> case. > > In my experience doing QA for browsers (mostly Gecko and Opera) the > intent of authors is to write content that works in a given set of > browsers. They typically could care less about standards. That they have > some boilerplate at the start is more the result of copy-and-paste than > actual knowledge of what is going on. When you tell developers what a > DOCTYPE actually does at a conference most are surprised. I don't disagree, I just would add Google Reader, NetNewsWire, and Planet Venus as user agents that people adapt their content to. FWIW, DOCTYPE is not relevant in such contexts. >> Meanwhile, many users of Planet Venus are serving their content as >> text/html. And I continue to have no way to prevent such. Nor do I >> have any desire to do so. > > I have no problem with that. I have a problem with resources pretending > to be different things depending on the interpreting user agent. I partly share that. Like you, I view as a problem whenever anybody makes the statement "my content is XHTML served as text/html". That being said, I do not see statements of the form "my content is XHTML but degrades gracefully" as a problem. >>>> [1] >>>> http://lists.w3.org/Archives/Public/public-html-xml/2011Jan/0025.html >>>> [2] http://intertwingly.net/blog/2010/12/30/Dealing-with-HTML-in-Feeds - Sam Ruby
Received on Wednesday, 5 January 2011 16:40:30 UTC