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