Re: Detailed review of 3.14.9. Media elements

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.


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


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


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


> > > 19. The spec does not define a way to stop media playback.
> > > 
> > > Currently, pause() is different from what stop() is in media 
> > > players.
> > > 
> > > I agree stop() can be implemented by Web applications *but* this is 
> > > a simple native function that should be available by default 
> > > (compare with cue points, which are great, but seem rather complex 
> > > for a first definition of the media element).
> > 
> > What's the use case?
> 
> Test case: open xmms/winamp/amarok/gmplayer/totem or some other media 
> player and try the pause/stop buttons. I think you agree, it's obvious 
> tons of online media player GUIs which will use the API defined by this 
> spec will implement the stop() method. For that matter, they'll most 
> likely implement their own half-working "playing" DOM property.

But what's the use of the stop() method? What does it do that's useful? 
Just because media players do it doesn't mean it's useful.

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

Received on Friday, 26 October 2007 23:06:53 UTC