- From: Simon Pieters <simonp@opera.com>
- Date: Wed, 29 Apr 2009 10:08:48 +0200
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: public-html <public-html@w3.org>
On Wed, 29 Apr 2009 01:16:25 +0200, Ian Hickson <ian@hixie.ch> wrote: > 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? No, sorry; please revert that change. The above was not properly thought through and doesn't actually solve the problem we were trying to solve. See instead point 3 in http://www.w3.org/mid/op.ur32svy5atwj1d@sisko.linkoping.osa and reply http://www.w3.org/mid/op.usdtzjm1atwj1d@sisko.linkoping.osa -- Simon Pieters Opera Software
Received on Wednesday, 29 April 2009 08:09:35 UTC