- From: Jamie Lokier <jamie@shareable.org>
- Date: Tue, 16 Jun 2009 19:23:04 +0100
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Simon Pieters <simonp@opera.com>, Ian Hickson <ian@hixie.ch>, Robert O'Callahan <robert@ocallahan.org>, Adam Barth <w3c@adambarth.com>, Larry Masinter <masinter@adobe.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, public-html@w3.org
Anne van Kesteren wrote: > On Tue, 16 Jun 2009 17:25:43 +0200, Jamie Lokier <jamie@shareable.org> wrote: > > Simon Pieters wrote: > >> On Fri, 12 Jun 2009 20:55:29 +0200, Ian Hickson <ian@hixie.ch> wrote: > >>> I've updated HTML5 to require that Content-Types of types that are not > >>> supported cause the resource to be ignored (even if it would otherwise > >>> be supported). > >> > >> If a UA does not know what is not supported, is it reasonable to > >> consider anything that is not video/* or audio/* to be not supported? > > > > For video, content negotiation is probably going to end up being done > > in Javascript rather than HTTP, or by User-Agent recognition. > > Still, if the user agent does a request, should it abort the request > if the media type of the response is not video/* or audio/*? I'm thinking if the response is an animated GIF, of type image/gif, why forbid a <video> element from being allowed to play it as a video. I'm also thinking, why forbid other image/* types from being played as static videos. After all, sometimes single-frame video/* files (such as an MPEG single I-Frame) are sometimes created for this purpose on real video players. It would seem odd to allow the display of single-frame video files, but forbid image/* files from behaving exactly the same way. -- Jamie
Received on Tuesday, 16 June 2009 18:23:44 UTC