- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 1 Dec 2008 07:29:09 +0000 (UTC)
- To: Eric Carlson <eric.carlson@apple.com>
- Cc: HTML WG <public-html@w3.org>
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