The current HTMLMediaElement interface is inconsistent and is designed in such
a way that making changes to it will be extremely difficult.
The network state is given by the networkState attribute, and is one of:
EMPTY, LOADING, LOADED_METADATA, LOADED_FIRST_FRAME, LOADED
The ready state is
Section 3.14.7.1, Video and audio codecs for video elements, currently says
this:
User agents should support Ogg Theora video and Ogg Vorbis audio, as well as
the Ogg container
format. [THEORA] [VORBIS] [OGG]
The language could be improved. Ogg Theora refers to Theora-encoded video
enclosed
From HTML 4.01:
type = content-type [CI]
This attribute specifies the content type for the data specified by data.
This attribute is
optional but recommended when data is specified since it allows the user agent
to avoid loading
information for unsupported content types. If the value of
--- Matthew Raymond [EMAIL PROTECTED] wrote:
It's all about ease of authoring. If you were new to HTML, would you
want to do this...
| object data=TheEarth.mpeg type=video/ogg-theora/object
...Or this...
| video src=TheEarth.mpeg/video
Do you know the MIME type for Ogg
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()
Can't such an API be provided for object elements that reference video?
The idea is
Will UAs be able to present an API to (X)HTML documents that conforms to both
the W3C DOM and the
WHATWG's HTML5 DOM?
If XHTML2 uses a different namespace from XHTML1, will UAs be able to treat
XHTML1 documents in a
way that conforms to both W3C and WHATWG specs?
If XHTML2 ends up using the
