- From: Oskar Welzl <oskar.welzl@pan.at>
- Date: Mon, 17 Nov 2003 22:04:48 +0100
- To: "W3C HTML List" <www-html@w3.org>
- Cc: <ernestcline@mindspring.com>
Ernest, > I've taken the time to make a thorough look at the type attribute. > I've reached somewhat different and considerably more detailed > conclusions than what I had before, which I explain in detail below. > These conclusions are: thx, that gives us something to work on > 1) The type attribute is not needed for resources retrieved using > HTTP or other protocols that provide a mechanism to indicate > the MIME type(s) of the resource. it is never needed, but always recommended; we needn't depend on the protocol here: as you say yourself in point 3), @type should be used to determine if the resource will be retrieved by the user agent. even with HTTP, it might be regarded useful for the UA *not* to contact the remote resource at all before deciding whether or not to fetch the file. (e.g. dial-up connection, page displayed offline; user will prefer UA not to occupy the phone line only to find out that it does not support PNG.) > 2) For those protocols for which a type attribute is needed, > a single valued type attribute containing but a single MIME type > is sufficient. Thus in the interest of simplicity and consistency, > the type attribute should keep its HTML4 format of a single type. agreed. it's not only for simplicity and consistency, i couldn't see a UA successfully "simulate" (as the current draft puts it) HTTPs behaviour in all possible situations; with multi-valued @types, we're bound to have browser dependent peculiarities when not using HTTP. > 3) The type attribute when present should be used to determine > if the resource will be retrieved by the user agent. agreed. > 4) XHTML2 should define what happens if a retrieved resource > does not match the type attributed to it via the type attribute > or other method. At a minimum, a user agent must be able to > provide an error message to the user and to present what > would be presented, had the resource not been retrieved. > Additional options as to what to do might be offered to the > user if they so choose. i'd rather stick to HTML 4.01 here: in case the MIMETYPE of the resource retrieved differs from what @type says, the UA should simply forget about @type and do what it would normally do with this kind of content (which, of course, *might* be to display an error message). the point, again, is: @type should be a hint about what will be on the other end of the line, so that the UA can make decisions *before* contacting the remote resource. as soon as the file is retrieved, though, we usually know what it is - and can act upon facts rather than upon hints. (of course, it may happen that after retrieving a file, we still don't know what it's supposed to be. in this case, again, the UA should try to apply the MIMETYPE given by @type. if this doesn't work, we'll have to present an error message.) regards, oskar
Received on Monday, 17 November 2003 16:03:31 UTC