- From: Joe D Williams <joedwil@earthlink.net>
- Date: Tue, 16 Jun 2009 17:00:12 -0700
- To: "Ian Hickson" <ian@hixie.ch>, "Robert O'Callahan" <robert@ocallahan.org>, "David Singer" <singer@apple.com>
- Cc: "Adam Barth" <w3c@adambarth.com>, "Larry Masinter" <masinter@adobe.com>, <ietf-http-wg@w3.org>, <public-html@w3.org>
> We're concerned about this, though we support the hope that we can > get away from doing content-type sniffing in this area. I hope so too. For <video> and <audio> it seems like a fairly specified contract about what can be expected to play in a W3C HTML 5 browser. Is sniffing always required? For <object> it has seemed like @data targets were sniffed, but for a param URL the url was sent to the player and the player essentially got to manage getting and running the content. If the allowed by the spec file extensions are listed then that will probably be enough to start out with. Trust the author to test before deployment. I would not expect to be using any particular media player, but one essentially built-in that is tuned to work with this spec. If I want _all_ the bells and whistles and the specific or optimized or (streaming?) file types and codecs provided by the major competitors in media players, then I will 'fallback' to <object> for possible access to maybe proprietary file extensions. What I as an author am looking for in these elements is a sure-fire way to get something running. From abstraction I would not expect to get the current default win/ie or apple/safari or realplayer or adobe whatever optioned media player, for example, or something else that the user may have installed and uses for the system default for the registered mimes, but instead the 'standard' simple, possibly restricted "no brand" player 'built-in' to the HTML 5 browser. This will not handle everything, but if it runs and I need more or different then maybe I can get user cooperation to bootstrap me into what might be more complex or effective interactive multiple media environment. So, me as the author knows the rules and what is supposed to be where I say it is so I would expect the host to get that <video> or <audio> player going with what I have put out there without a lot of delay and questions. On the other hand, if I don't know what is coming in and I wanted to try <video> first and I got an unsupported (by <video> or <audio>) MIME or file extension, then I would have to fallback to <object> to try and handle it by @type and/or @classid selection with what might end up to be the actual current user specified default player for the browser host platform . I think the reason for host browser needing to sniff content streams in general is not so much needed in this case. Perhaps the file extensions for these element's content are more well known and better defined than their MIMEs. Since the author should know (I mean if tested at home; it should work on the WWW!). So I would say in this case it is not possible to recommend actual sniffing by the host browser past the file extension. Maybe in these cases of <audio> and <video> if the file extension is recognized, treat it if @type was +xml and just pass the URL to the handler and let it start to work it out? Thank You and Best Regards, Joe
Received on Wednesday, 17 June 2009 00:01:54 UTC