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

Re: <video> feedback

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>
Message-ID: <Pine.LNX.4.62.0904282307340.10370@hixie.dreamhostps.com>
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 GMT

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