> 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