[whatwg] Some media element details
ian at hixie.ch
Wed May 14 23:37:41 PDT 2008
On Mon, 14 Jan 2008, Antti Koivisto wrote:
> Some comments about the media elements:
> > 220.127.116.11. Loading the media resource
> > The user agent must then set the begun flag to true and fire a progress
> > event called begin at the media element.
> The progress event draft calls this event "loadstart" (and occasionally
> "start," that spec is not very consistent). No matter which name is
> chosen, it would be nice if it was same everywhere.
> > 18.104.22.168. Playing the media resource
> It is not entirely clear from descriptions of play() and pause() if the
> timeupdate, ratechange, play and paused events should all be fired
> asynchronously, though I assume that is the idea.
> It would be nice to have a read-only attribute (called "playing" for
> example) that would be true when the element is "actively playing".
> Knowing if the playback is progressing is necessary for implementing
> basic playback UIs with JS. It is clumsy and not very obvious that you
> need to do "var playing = !video.paused && !video.ended &&
> video.readyState >= HTMLMediaElement.CAN_PLAY" to get this information.
What's the use case?
> > When a media element is removed from a Document, the user agent must
> > act as if the pause() method had been invoked.
> Calling pause() will invoke load() in case the network state is EMPTY.
> This seems like wrong thing to do on remove. The above should be
> modified to invoke pause() only if the network state is greater than
> It might also be good to explicitly state that exceptions are ignored.
> > 22.214.171.124. Seeking
> > 3. If currentLoop is equal to the value of playCount, let...
> Should be "equal to the value of playCount - 1".
> > As soon as the user agent has established whether or not the media data for
> > the new playback position is available, and, if it is, decoded enough data
> > to play back that position, the seeking DOM attribute must be set to false.
> There is no event of any kind associated with seeking attribute becoming false
> which makes it difficult to react to changes in seeking state. It might be a
> good idea to fire a "timeupdate" here.
I've added 'seeking' and 'seeked' events.
> > ... notwithstanding the looping attributes (i.e. the effective start
> > and effective end, etc, don't affect the seeking attribute).
> Should be "don't affect the seekable attribute".
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg