[whatwg] Some media element details

Antti Koivisto antti at apple.com
Mon Jan 14 10:18:07 PST 2008


Hello,

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.

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

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.

> 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. It might also be good to explicitly state that exceptions are  
ignored.

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

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

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


   antti




More information about the whatwg mailing list