W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2008

[whatwg] Some media element details

From: James Justin Harrell <herorev@yahoo.com>
Date: Fri, 16 May 2008 21:29:12 -0700 (PDT)
Message-ID: <459059.20805.qm@web50107.mail.re2.yahoo.com>
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 given by the "readyState" attribute, and is one of:
DATA_UNAVAILABLE, CAN_SHOW_CURRENT_FRAME, CAN_PLAY, CAN_PLAY_THROUGH

Although adding states for either of these would not be fun, it could be done. But the playback state is different.

The consistent and upgradeable design would be to have a "playbackState" attribute that is one of:
PAUSED, PLAYING

But because there are currently only two states, we instead have a single boolean attribute. Boolean attributes are great when you're sure there will always be only two states, but they're terrible if there's a chance you'll want to add additional states.

It isn't difficult to imagine all kinds of additional playback states. For example, what if there was great demand for forward-seeking and backward-seeking states? (e.g. the states that are usually associated with those >> and << buttons) How could those states be added?

The media error state is also inconsistent, and this time for no apparent reason, although it would at least be easy to update. A more consistent design would be to have an "errorState" attribute that is one of:
NO_ERROR, ABORTED, NETWORK_ERROR, DECODING_ERROR

And why are the error state names prefixed with "MEDIA_ERR" when the names for the other states are not prefixed? e.g. LOADING instead of MEDIA_NET_LOADING.

If NO_ERROR was given a value of 0, testing for an error with this design wouldn't be any more difficult.

if( videoElement.error ) {...}
if( videoElement.errorState ) {...}


----- Original Message ----

> Wouldn't you want something like that to know, for example, whether to 
> display a "play" or a "pause" button?

We have that -- the "paused" attribute. When it's true, show play, and 
when it's paused, show false. You don't want to show play when the reason 
you aren't playing is that you're buffered or seeking for instance. The 
client is trying to play. It can't.
Received on Friday, 16 May 2008 21:29:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:02 UTC