Re: Acessibility of <audio> and <video>

Dave Singer wrote:
> No, you're missing something.  You're assuming that the only 
> pluggability is with <object>.  Nothing about the spec. stops browsers from
> a) implementing their own plug-in model for video and audio source
> b) looking for optional platforms such as VLC, MPEG4FF, QuickTime, and 
> so on
> c) asking one or more of those platforms, dynamically, what they can 
> support

No, I don't think I'm missing anything.  I'm just approaching this as an 
author, not as a UA implementor.  As an author I would like to be able 
to use <video> (because it's semantically cleaner than <object> and 
allows the user to select a UI they most prefer for it),  but at the 
same time I don't want to have to sort out which codecs UAs support or 
don't support, and I know every single UA has Flash installed.

So I want to be able to point to my video, with fallback to Flash if the 
browser can't handle it.  Note that from an author's point of view there 
is no difference between "UA doesn't support <video>" and "UA doesn't 
support codec X".

Or are you saying that I should point one of the <source>s to my swf 
file and that it's the UA's responsibility to handle that situation by 
delegating to the existing Flash plug-in?

That seems to be a pretty serious burden on UAs, and in view of the 
abovementioned "no difference from an author's point of view" I question 
the need for that burden.

> <objects> have varying DOM interface, UI behavior, and so on.  We're 
> trying really hard to unify the support for multimedia here.

Yes, I know what the goal is, thank you.  I just want, as an author, to 
be able to use <video> without serious pain in the near future.  As a UA 
implementor, I suspect doing fallback to the content inside <video> is a 
lot simpler than doing something sane with the incoming swf from a 
<source>.  But I could be wrong, of course.

-Boris

Received on Tuesday, 26 August 2008 12:58:27 UTC