[whatwg] <video> element proposal

[Spartanicus]

"Anne van Kesteren" <annevk at opera.com> wrote:

>Opera has some internal expiremental builds with an implementation of a  
><video> element.

I've observed widespread frustration amongst authors on how to offer
audio and/or video on web pages. Quite a few have started using Flash
since apparently it takes some of the pain out of doing so. That seems
to warrant looking at a solution that doesn't use a proprietary
technology like Flash.

>When the src="" attribute is set, the user agent must immediately begin to
>download the specified resource, unless the user agent cannot support videos,
>or its support for videos has been disabled. As soon as enough data is
>received the user agent should start decoding the video. This means that
>play() and other methods can already be used before the resource is downloaded
>completely.

I strongly dislike audio and/or video that automatically downloads and
starts playing automatically, so much so that I've disabled media player
plugins altogether. Both audio and video files are often considerable in
size. I don't want my web browser to start making noise unless I've
explicitly chosen to play audio, this should not be the result of simply
loading a web page. I'd favour a spec requirement that a UA must offer
users a configuration option not to automatically download and start
audio and/or video and let the user decide first.

Another current common frustration amongst authors is how to get file
based media files to play before they've been fully downloaded. This is
currently achieved by using text based redirector files containing the
url to the actual media file, but these redirector formats have only
been defined for a limited number of media formats. That would suggest
that a UA could by default employ progressive downloading.

>Issue: should we very much like the <img> element just ignore 404 errors and
>the Content-Type header?

And use the file extension or content sniffing? Using file extensions
doesn't seem possible given the existence of wrapper formats. I imagine
that a browser that can handle JPEG, PNG and GIF can use content
sniffing and depending on the outcome feed it to the right decoder. I'm
having difficulty imagining how that would work with video. Wouldn't
that require a UA to at least be able to open the file headers of the
many video file formats out there to sniff what media format is actually
inside them before it can decide where to send the data?

>Issue: height / width

Currently an issue with supplying height and width for video content
embedded with the object element is that the supplied width and height
includes the chrome and UI controls of the embedded player. That creates
problems for authors who often don't know the size of those elements in
advance, it may depend on the player and/or player skin they use.
Scaling video can be very GPU intensive, so it would be helpful if there
was a way to ensure that video can play in it's native size, whilst at
the same time knowing in advance what room to reserve in the flow for
the media and any player chrome.

-- 
Spartanicus

(email whitelist in use, non list-server mail will not be seen)