[whatwg] HTML5 video element - default to fallback in cases where UA can't play format

[Kit Grose]

G'day Gregory,

Thanks for the explanation. While I understand the issue you present  
with precedence of JS and fallback content, I can't off the top of my  
head come up with any necessary uses for the canPlayType function  
(maybe as a nice-to-have, of course) had the behaviour worked more  
predictably—particularly if the tradeoff is a totally non-workable  
solution in modern browsers with NoScript turned on in situations like  
mine. What happens if/when IE comes to the party but requires WMV  
output? Will we all then encode *three* of the same video just to get  
broader support? I can't see the complexity of that operation every  
trumping the ease of use (from a content producer's end) of a single  
FLV with a Flash video player, which is surely the ultimate goal here.

As far as the standards compliance etc. goes; the site is not client  
work, and isn't going to be deployed/marketed as a standard website  
(hence my taking a risk on using the HTML5 doctype at all).

The trade-offs for us to implement OGG—in this particular case, at  
least—just for the sake of idealism aren't worth the maintenance cost  
penalty we'd pay by providing (encoding, hosting, etc., etc.) two  
video formats; the site will explicitly target users we know to use IE  
for the most part, but should also work on the iPhone (the customer is  
ourselves). That made V4E a good fit and I was keen to experiment with  
the video element myself anyway.

I just found the behaviour of the element highly contrary to what I  
had expected and wanted to raise it as a concern.

—Kit

On 28/10/2009, at 12:28 PM, Gregory Maxwell wrote:

> On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose <kit at iqmultimedia.com.au>  
> wrote:
> [snip]
>> I expected (incorrectly, in this case) that if I only produced one
>> source element (an MP4), Firefox would drop down to use the fallback
>> content, as it does if I include an object element for a format not
>> supported (for example, if I include a QuickTime object and QT is not
> [snip]
>
> Please see the list archives:
> http://www.mail-archive.com/whatwg@lists.whatwg.org/msg16092.html
>
> In short, there are corner cases which make this untenable. E.g. what
> happens when you have JS doing brilliant canplaytype magic, but also
> provide tag-interior fallbacks for clients which may not even have JS?
> They'll fire off and start before your JS has a chance to do its
> canplaytype magic.
>
>
> Of course, "standards-compliant HTML/XHTML using CSS and Javascript as
> required by the design", as your products are described, is pretty
> meaningless when its applied to sites no more compatible than the bad
> old "Works best in IE" days, only it's now Apple™ and Adobe™.  I urge
> you to consider the values of an open and interoperable web against
> the costs, and I hope you are informing your customer(s) about any
> long term licensing fees for the formats chosen for their site.