Re: Media element events

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.

So, how about making all of
loadedmetadata
loadeddata <-- what is the use case for this?
waiting
playing
canplay
canplaythrough <-- the old ready state names!

into a single readystatechange event?

Since the network state is linked to progress events I wouldn't suggest
removing them, also seeing as some of them aren't state changes at all
(progress and stalled).

Philip

On Tue, 2008-12-02 at 20:51 +0000, Ian Hickson wrote:
> On Tue, 2 Dec 2008, Simon Pieters wrote:
> > 
> > The spec doesn't have any event handler attributes for them, but has for 
> > seemingly all other events. Firefox seems to support at least <video 
> > onloadstart>. Catching the 'loadstart' event is not possible without a 
> > content event handler attribute if you have <video src> in the markup. 
> > XHR has DOM event handler attributes for progress events. So it seems a 
> > bit weird that <video> doesn't have them. Is it intentional?
> 
> The intent is that all events defined in HTML5 have corresponding event 
> attributes (on all elements and Window), I just haven't gone through and 
> actually defined them all yet.
> 
> 
> > Another thing is that there are quite many events. The use cases for all 
> > events aren't clear to us. Maybe some of them could be grouped together 
> > into a single readystatechange event? Maybe also networkstatechange? 
> > Maybe some could be dropped?
> 
> Why is having a lot of events a problem?
> 
> 
> On Tue, 2 Dec 2008, Eric Carlson wrote:
> >
> > I agree that there are a lot of events, and actually we have also been 
> > talking about coalescing all of the ready state and network state events 
> > into readystatechange and networkstatechange. One potential problem with 
> > this is that a script could miss state transitions because the 
> > readyState or networkState attributes may have changed between the time 
> > an event is posted and when the script's listener is triggered. I 
> > haven't thought this through enough to know if it will be a serious 
> > problem or not.
> 
> Experience with onreadystatechange with XMLHttpRequest also suggests that 
> it is a bad authoring experience, as people just end up doing:
> 
>    o.onreadystatechange = function(e) {
>      if (o.readyState == x) {
>        ...
>      }
>    }
> 
> ...for the case "x" that they want. Having individual events just seems 
> saner given this idiom.
> 
-- 
Philip Jägenstedt
Opera Software

Received on Thursday, 4 December 2008 10:15:47 UTC