- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 28 Apr 2009 23:16:25 +0000 (UTC)
- To: Simon Pieters <simonp@opera.com>
- Cc: public-html <public-html@w3.org>
On Thu, 26 Mar 2009, Simon Pieters wrote: > On Wed, 25 Mar 2009 23:11:53 +0100, Ian Hickson <ian@hixie.ch> wrote: > > > > > > It seems more predictable and useful to fire an error event at the > > > media element at the point you find a <source> (or <video src>) that > > > is not supported. (Also more consistent with <img> -- without a > > > src="" you don't get an error event.) error.code could say > > > MEDIA_ERR_NOT_SUPPORTED instead, and the MediaError interface could > > > gain another attribute (say error.src) that is set to the value of > > > .currentSrc at the time the error occurred. (Since the algorithm is > > > async authors can't just look at .currentSrc since it might have > > > changed before the event handler looks at it.) > > > > The idea of the error event in this particular case is to let the page > > show a message, which would be overridden by the loadedmetadata > > event's handler, or some such. I suppose we could just fire an event > > for each unsupported resource, though... what are the other use cases? > > Maybe the message would contain pointers to codecs for the failed > videos. I've made the algorithm fire 'error' events at the <source> element (without changing the current rules about the media element). Does that work? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 28 April 2009 23:17:00 UTC