Ajax Girl

Opera has published a proposal (that is implemented in an internal build) for a <video> HTML element.

This has been talked about for quite awhile, and they got around to doing it.

Example

[html]

function play(video) { document.getElementById(video).play() }
function pause(video) { document.getElementById(video).pause() }
function stop(video) { document.getElementById(video).stop() }

… description of the news …
Play the news!
Pause the news!
Reset
[html]

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.

Any opinions on the issues?

• Should we very much like the element just ignore 404 errors and
  the Content-Type header?
• 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.
• Maybe have a loop([times]) member like Audio() has?
• height / width

Ready to get rid of generic ugly object/embed tags?

Source: Ajaxian
Original Article: http://ajaxian.com/archives/opera-element-proposal