On Fri, 16 May 2008, James Justin Harrell wrote: > > 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?
This is already supported, and is independent of the pause state. (You could easily imagine a UI where you could pause while fast-forwarding.) > 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 We want to be able to include much more information, hence the use of an object for now. > 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. The other state constants are prefixed (LOAD and CAN_ respectively) except for the zero state (which doesn't have a constant at all for errors). On Fri, 16 May 2008, Maciej Stachowiak wrote: > > > > 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. > > I'm not sure adding states is all that safe. Any code that does a switch > on the state would now fall through to an untested code path. Indeed, we're unlikely to ever add states, we're more likely to add orthogonal attributes. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
