On Mon, 26 Jul 2010 14:53:50 +0200, Silvia Pfeiffer
<silviapfeiff...@gmail.com> wrote:
On Mon, Jul 26, 2010 at 7:41 PM, Philip Jägenstedt
<phil...@opera.com>wrote:
I actually don't think there's anything wrong about the spec as it is.
NETWORK_NO_SOURCE is not a state of failure, it is a waiting state.
Here's
what happens as the parser inserts elements into the DOM:
<video controls width="400px">
<!-- video has been inserted but resource selection hasn't run -->
<source type="video/mp4">
<!-- resource selection is started, ends on step 21 with
NETWORK_NO_SOURCE
and pointer pointing to just after the only source element -->
<source type="video/webm">
<!-- resource selection continues at step 22, going another loop and
ending
at step 21, but with pointer pointer to after the second source element
-->
<source type="video/ogg">
<-- same as above, but pointing to after the third source element -->
</video>
If nothing is done, the resource selection algorithm will wait forever
at
step 21. To get out of that state you have to either call load() to
restart
resource selection, or append another source element.
If we should let networkState be NETWORK_EMPTY after inserting the dummy
<source> elements, then resource selection would be run from the
beginning
each time, which means that during parsing, the first <source> element
will
be considered 3 times, the second 2 times and the last 1 time. In your
example this doesn't matter, but if the reason a <source> failed was
because
of network errors, unsupported Content-Type or an unsupported file
format,
then that will also happen too many times, adding useless network
traffic
(unless e.g. 404 results are cached).
So, I think the algorithm should stay as it is and that the other
browsers
should change their implementations. In your original example you used
<source> elements with no src attribute. This is invalid, and I think
the
proper solution would be to create each source element, set the src
attribute and append it to the video element.
Ok, I re-read the spec about <source> and you are correct: it's invalid
to
create <source> elements without a @src attribute. It could, however,
still
be created without a URI, in which case the resulting state would indeed
be
a NETWORK_NO_SOURCE, since it fails to find a valid @currentSrc .
I still think, though, that NETWORK_NO_SOURCE is a failure state, since
it
is specified as
NETWORK_NO_SOURCE (numeric value 3):
The element's resource selection algorithm is active, but it has
failed
to find a resource to use.
Perhaps this wording should be changed. Given that this state is an
integral part of skipping <source> elements where the type or media isn't
supported, I really wouldn't call it a failure state, it's rather a
waiting state.
I now wonder about the intention of play() (and also of pause()). As I
understood it, they are both meant to reload the media resource if
@currentSrc has changed, similar to what load() is supposed to do.
What the spec actually does right now is cause a change of the src
attribute to trigger resource selection. There are no hooks for when you
change the src attribute of a child source element, so that's why it looks
a bit inconsistent. play() and pause() only trigger resource selection if
it hasn't already been started.
Also, I wonder what NETWORK_EMPTY is used for when not at the beginning
of
parsing the media resource. I haven't managed to catch Opera in that
state.
A newly created media element will have networkState NETWORK_EMPTY, so
that's what you will see just after it is inserted into the DOM by the
parser (given that it has no src attribute, because setting the src
attribute might change the state) or on a newly created element from
document.createElement('video'). As you've noticed you don't often see
this state as an author, because almost anything you do triggers resource
selection.
--
Philip Jägenstedt
Core Developer
Opera Software
