Re: Detailed review of 3.14.9. Media elements

Hello Ian!

Thanks for the reply.

Le Sat, 27 Oct 2007 02:06:43 +0300, Ian Hickson <> a écrit:

> On Fri, 19 Oct 2007, Mihai Sucan wrote:
>> > >
>> > > The UA should fire a simple event called "mutetoggle" when the media
>> > > is muted/unmuted.
>> >
>> > Having two events seems like overkill for this.
>> I was suggesting to only fire a simple event called "mutetoggle" when
>> the media is muted/unmuted - no "volumechange" event.
>> The "volumechange" event should only be fired when the volume actually
>> changes.
> Right, I just meant that having two events (mutetoggle and volumechange)
> would be overkill compared to just having the one (volumechange) firing
> for both.

Ok then. Not much I can add to this.

>> > > "The playing DOM attribute represents whether the media element is
>> > > actively playing or not. The attribute must initially be false."
>> >
>> > I actually agree with this, but there has been some pushback before.
>> > What do people think? Should we add this feature? It would be easy.
>> Pushback for something so obvious? Why? What can someone argue against
>> the playing DOM attribute?
> We want to avoid feature creep, with more API surface area than  
> absolutely
> necessary. Right now we have quite a tight (albeit large) API, with very
> little redundancy.

I wouldn't call this feature belonging to the "feature creep" category.  
Cue points are "feature creep". It's interesting they made it into the  
first version of the API - this could suggest to me there's corporate  
interest in cue points (?).

>> > > 17. The spec is missing the definition of a scriptable way to abort
>> > > the loading of the media element.
>> >
>> > Just remove the <source> elements and src="" attribute, and call
>> > load() again.
>> That's not an ideal solution. If I remove all the <source> elements and
>> the src attribute, I have to re-add them once I want to play the media
>> again.
> Yes. But what's the use case? Why would you abort loading?

Asking why would you abort loading of media elements is like asking why  
would a download manager abort file downloads, or why any other software  
application would ever abort any file download, for any possible purpose.

*Why* would they abort downloads? After all the user wanted the file.

As a user, I don't like I can't abort/stop loading videos on YouTube,  
Dailymotion, Stage6 and other similar sites. This is not the way software  
media players work: when I play a file with mplayer over the network, if I  
pause/stop playback, the player stops using my network resources. I like  
that. I would like a similar "feature" in online media players as well.

I can't provide further arguments to why would a Web application abort  
media loading. I see this as "there's an infinite set of use-cases", but I  
have no precise example.

>> > If you don't want it to autoload, just don't set the source yet.
>> This is not an ideal solution. In a document where the author doesn't
>> want to use any scripting, he would simply add the media elements, with
>> the associated <source> elements. As an author, I would expect I can
>> enable/disable automatic media downloading and automatic media playback,
>> without any scripting.
> True, we don't really have a good story on that end yet... What do people
> think? How should we address this? I hesitate to add yet more
> attributes... We could have auto=play auto=load instead of autoplay...?

This issue is similar to the one above, and similar to the GUI controls  
issue ("we want native controls by default" - me as well).

Auto=play, auto=load, auto=none sounds good to me - auto=play being the  


Mihai Sucan

Received on Saturday, 27 October 2007 08:28:33 UTC