W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: Media element events

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 21 Feb 2009 07:05:12 +0000 (UTC)
To: Philip Jägenstedt <philipj@opera.com>
Cc: Simon Pieters <simonp@opera.com>, Eric Carlson <eric.carlson@apple.com>, public-html <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0902210023540.6209@hixie.dreamhostps.com>
On Thu, 4 Dec 2008, Philip Jägenstedt wrote:
>
> Defining one event per state transition strikes me rather awkward, 
> unless this is really necessary I'd rather have state change events. If 
> there's no way to detect an arbitrary state change then we have to 
> define an event for each transition for which we can think of a use 
> case. Other transitions simply can't be detected without polling.
> 
> If it's a problem that state transitions may be missed, how about a 
> StateChangeEvent with attributes oldstate and newstate? This is how some 
> media frameworks work.

The events each came about based on use cases, I believe.

The problem with a generic state change event is seen by the pattern we 
always see for onreadystatechange on XHR: people who want just one case 
end up having boilerplate "if (this is the case i want) {}" code. I don't 
think that's really a good pattern. Do we have reason to believe that 
anyone who cares about one of these events would care about all of them? 
If seems to me that in all cases of ready state changing, either the use 
case is going to be pretty specific, e.g. starting playback on 
canplaythrough, or showing and hiding a busy indicator when the waiting 
and playing events fire, etc. You wouldn't want to have both of these 
activities jammed into the same event handler, and having multiple event 
handlers all registered for the same event but each immediately just 
checking the state and bailing if it's not the state they want seems like 
it would just be a pain for authors (like XHR).


> loadeddata <-- what is the use case for this?

It lets the script know when it can switch out a poster frame, if it is 
doing something more complex than poster="" would allow.


> canplay
> canplaythrough <-- the old ready state names!

Yeah, I kept the old names because onhavefuturedata and onhaveenoughdata 
didn't really scan as well.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 21 February 2009 07:05:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:32 GMT