Re: HTMLMediaElement readyState

On Wed, 19 Nov 2008, Eric Carlson wrote:
> 
> First, HAVE_SOME_DATA is unnecessary because it describes the same state 
> as HAVE_METADATA - the UA doesn't have enough media to render anything. 
> It is true that HAVE_SOME_DATA tells you there is data *somewhere* that 
> can be displayed, but that isn't terribly useful.

Good point; fixed.


> The second, and more important, problem is that the states are written 
> (a) from the point of view of how the resource feels about itself 
> instead of how it can be used, and (b) they are quite download-centric.  

I don't really see this as a problem...


> For example the spec says a media resource can be played when it is in 
> the HAVE_FUTURE_DATA state, but a 'playable' streaming resource may have 
> *zero* future data when it is as playable as it will ever be - it just 
> has a network connection over which it can request the server to begin 
> playing.

That would be the HAVE_METADATA or HAVE_CURRENT_DATA state; only once 
data is coming in, with actual data in the streaming buffer, would it get 
to HAVE_FUTURE_DATA.


> The state descriptions have been rewritten below to accommodate streamed 
> media resources

The text in the spec now is already intended to accommodate streamed media 
resources. What isn't accommodated?


> and we have changed the state prefixes from "HAVE_" to "CAN_" to 
> emphasize that the states describe what can be done with the element.

I don't really understand why this is better. Could you elaborate?


> CAN_PLAY (numeric value 3)

This is IMHO a misleading constant name; you can play all the way from 
HAVE_NOTHING, it's just that it'll take a while to get some data.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 1 December 2008 07:29:45 UTC