[whatwg] video element not ready for prime time

[Boris Zbarsky]

On 1/12/12 12:46 PM, Francis Boumphrey wrote:
> and as far as I can see there is no way for me as an author to
> know that the video is not being played

If true, this should be simple to fix.  But I would think that there was 
a way to detect this via the readyState or error properties.  In 
particular, if the error.code is MEDIA_ERR_SRC_NOT_SUPPORTED that would 
seem to be a strong indication that the format could not be played, right?

> Even here I have a problem. In which order does the user-agent check the
> source files (in Chrome it seems to be in the order in which they are
> written, but there is no guidance here in the spec.

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-media-load-algorithm 
step 3 says:

   Otherwise, if the media element does not have a src attribute but has
   a source element child, then let mode be children and let candidate
   be the first such source element child in tree order.

and same section starting at "Otherwise, the source elements will be 
used; run these substeps:" explicitly talks about trying the <source> 
elements in document order.

So what Chrome is doing is exactly what the spec requires.

> Also will my user agent down-load the file that it cannot play, thus using
> up band-width?

That's up to the to some extent UA, but I'd think that if you list a 
type="whatever" and the UA doesn't support the type, any sane UA would 
skip the download.  Specifically, see substep 5 of the "run these 
substeps" section mentioned above:

   5. If candidate has a type attribute whose value, when parsed as a
   MIME type (including any codecs described by the codecs parameter,
   for types that define that parameter), represents a type that the
   user agent knows it cannot render, then end the synchronous section,
   and jump down to the failed step below.

So the only way for a UA to not skip the <source> is if it doesn't know 
it can't render the type.

-Boris