[whatwg] Some media element details

[Ian Hickson]

On Mon, 14 Jan 2008, Antti Koivisto wrote:
> 
> Some comments about the media elements:
> 
> > 3.14.9.4. 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.

Fixed.


> > 3.14.9.7. 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.

Fixed.


> 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 
> EMPTY.

Fixed.


> It might also be good to explicitly state that exceptions are ignored.

Which exceptions?


> > 3.14.9.8. Seeking
> > 
> > 3. If currentLoop is equal to the value of playCount, let...
> 
> Should be "equal to the value of playCount - 1".

Fixed.


> > 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".

Fixed.

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