- From: Robert J Burns <rob@robburns.com>
- Date: Tue, 20 Jan 2009 12:07:45 -0600
- To: HTML WG <public-html@w3.org>
Hi Karl, On Jan 20, 2009, at 11:46 AM, Karl Dubost wrote: > > > Le 20 janv. 2009 à 12:41, Boris Zbarsky a écrit : >> Karl Dubost wrote: >>> How do I know what was the intent of the author when the file is >>> on the desktop and mimetype less? html 5 (text/html) or html 5 >>> (application/xhtml+xml) >> >> Note that we already have this problem with XHTML 1 too. It's >> usually resolved by looking at the extension... One could also >> look for xmlns on the root, though there's nothing preventing the >> text/html version from having that, of course. > > > for browsers only… > for authoring tools they look at the doctype or tidy in the case of > my email. As an authoring tool implementor, I can tell you that I see very little difference between the http protocol for attaching mime type and the the various OS approaches to attaching type information to a resource. In either case, much of it is handled by filename extension mappings, but with various override methods. So in most any environment, an application can query various APIs to discover the official content-type of a resource. There are problems with protocols that do not relay content type information (and charset information) and therefore break the grapevine so to speak (e.g., FTP). However, fortunately those protocols are used less frequently everyday. Moreover, there's no reason to expect such a resource with broken content-type information ends up on the desktop anymore than such a resource ends up on an http server. So the problem can arise in either environment. So I would say, if something like HTMLTidy is not using the recommended OS protocols to determine resource type, that should be considered a bug (though I must admit I'm less familiar with how this information gets used in a posix API layer and perhaps there isn't a clear posix approach for conveying type information so HTMLTidy might be excused a bit in trying to be cross-platform). Take care, Rob
Received on Tuesday, 20 January 2009 18:08:27 UTC