Hi,
Opera has some internal expiremental builds with an implementation of a
<video> element. The element exposes a simple API (for the moment) much
like the Audio() object:
play()
pause()
stop()
The idea is that it works like <object> except that it has special <video>
semantics much like <img> has image semantics. In markup you could prolly
use it as follows:
<figure>
<video src=news-snippet.ogg>
...
</video>
<legend>HTML5 in BBC News</legend>
</figure>
I attached a proposal for the element and as you can see there are still
some open issues. The element and its API are of course open for debate.
We're not enforcing this upon the world ;-)
Cheers,
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
This specification uses the terminology as found in HTML5.
The <video> element
Inline-level embedded content
Contexts in which this element may be used:
As the only embedded content child of a <figure> element.
Where inline-level content is allowed.
Content model:
Inline-level content.
Element-specific attributes:
src
height
width
Predefined classes that apply to this element:
None
DOM Interface
interface HTMLVideoElement : HTMLElement {
attribute DOMString src;
attribute long height;
attribute long width;
void play();
void pause();
void stop();
};
The src="" attribute, if present, specifies the address of the video. If
present, the attribute must be a URI (or IRI).
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.
When downloading a video resource HTTP pipelining must not be used.
If the download fails, the resource is not a supported video format or the
resource can't be decoded due to an error the user agent must fire an error
event on the <video> element and if it was still downloading it must abort
that process.
Issue: should we very much like the <img> element just ignore 404 errors and
the Content-Type header?
Issue: we could dispatch a load event once the complete video is downloaded,
but it probably makes more sense to have some kind of streaming here. Perhaps
the process event stuff from Web API is even enough if a Content-Length header
is provided.
If the error element is dispatched or videos are not supported or support for
it has been disabled the <video> element doesn't represent anything except
what the element's contents represent. This is the element's fallback content.
Each video element has a current position. This is initially zero.
When play() is invoked the video begins to play at the current position.
When pause() is invoked the video is stopped at the current position which is
now the new current position.
When stop() is invoked the video is stopped and the current position is reset
to zero.
| <script>
| function play(video) { document.getElementById(video).play() }
| function pause(video) { document.getElementById(video).pause() }
| function stop(video) { document.getElementById(video).stop() }
| </script>
| <p><video src=news.ogg id=news> ... description of the news ... </video></p>
| <p><button onclick=play('news')>Play the news!</button></p>
| <p><button onclick=pause('news')>Pause the news!</button></p>
| <p><button onclick=stop('news')>Reset</button></p>
When playback of the video reaches the end of the available data, its current
position is reset to the start of the clip.
Issue: Maybe have a loop([times]) member like Audio() has?
Issue: height / width
