- From: Joe D Williams <joedwil@earthlink.net>
- Date: Wed, 17 Jun 2009 10:42:39 -0700
- To: "Jonas Sicking" <jonas@sicking.cc>, "Mark Nottingham" <mnot@mnot.net>
- Cc: "Dave Singer" <singer@apple.com>, "Shane McCarron" <shane@aptest.com>, <robert@ocallahan.org>, "Ian Hickson" <ian@hixie.ch>, "Adam Barth" <w3c@adambarth.com>, "Larry Masinter" <masinter@adobe.com>, <ietf-http-wg@w3.org>, <public-html@w3.org>
> but why can't I as a user turn it off, either as a preference or on > a case-by-case basis? Sometimes "going the extra mile" gets it > wrong, and as with any heuristic, there needs to be a way to say > "no, don't do that!" Well, lets give both author and the actual browser pilot a chance. First, from authoring, for <audio> and <video> the author can present from a small, safe group of content models using simple reference to file MIME and file extension. These are first class objects; the element is a trusted context that can negotiate directly with the host DOM. These are active, live nodes but their content is not active. Until these spec <audio> and <video> MIMEs are officially registered and the servers are actually updated, or the author can produce .htaccess file to control the served ContentType, the server response is uncertain. So at this time and in the future, the server may actually produce the target content with no content type string. In fact, the only information that needs to be be relied upon at this point is that if the author says audio me.ogg then the UA either: 1. fetches the resource for sniffing then sends it to the media handler, or 2 sends the handler the absolute URL and leaves until the handler context needs it again. I think 2 is preferred. Next, from the browser user, since <audio> and <video> are first class objects, there are no special permissions required to render asap, In particular, there are no "Security" issues. Default is as the author specified for the current object. Although UA might provide some common means of defining use preferences to allow local control of the browing environment produced by particular pieces of the document it is on same order as the choices provide by the author with @sandbox. or CSS. If any halt or significant delay is produced by these user-selected UA actions, the fallback content must be rendered, then replaced by the parent content when approved. As for UA sniffing of this particular <audio> or <video> content, it is useless and counter-productive. First, for these types, no matter what goes into the handler. the content can only confuse or break the handler not its container. Next, although a fine idea, we are unlikely to find a MIME-like string in the essentially binary file we want the handler to be dealing with. There are metadata in there, and the whole thing could be XML someday but only the handler needs to know about that in this case. For example, no matter what the served or sniffed MIME, if the author said ogg then the handler will treat the content only as ogg. Can there be scripts or any other 'security' issues in these content types? I will check more about ogg, but for .wav, I find that any suffix to .wav to tell more about the particular internal data is for internal production sorting convenience in authoring tools, maybe. Otherwise, you do have to actually read some file front matter to determine some actual characteristics, such as sample rate, and others. These are of no value to the UA or the handler in this instance because a handler that does .wav is not going to have trouble with any spec form of the .wav. PDM is just the best open choice of other mod alternatives. Again, if it works on a couple of HTML 5 browsers at home, then it should just work out there in the HTML 5 WWW. Thank You and Best Regards, Joe
Received on Wednesday, 17 June 2009 17:43:30 UTC