- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 10 Aug 2010 10:40:39 +0200
On Mon, 09 Aug 2010 18:35:47 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 8/9/10 12:14 PM, Philip J?genstedt wrote:
>>> Why? Maybe if I understood what we're trying to accomplish with the
>>> synchronous section bit here I'd have a better idea of how it should
>>> work...
>>
>> The general idea of waiting is that since the following steps of the
>> resource selection algorithm inspects video elements src attribute and
>> source element children, those should be in a consistent state before
>> the checking is done.
>
> OK, but then why are we not imposing such a requirement for the case
> when the <video> is being created by the parser?
Because the parser can't create a state which the algorithm doesn't
handle. It always first inserts the video element, then the source
elements in the order they should be evaluated. The algorithm is written
in such a way that the overall result is the same regardless of whether it
is invoked/continued on each inserted source element or after the video
element is closed. However, scripts can see the state at any point, which
is why it needs to be the same in all browsers.
>> <body>
>> <script>
>> var v = document.createElement('video');
>> var exts=["webm", "mp4"];
>> exts.forEach(function(ext) {
>> var s = document.createElement('source');
>> v.appendChild(s);
>> s.src = "foo."+ext;
>> s.type = "video/"+ext;
>> document.body.appendChild(v);
>> });
>> </script>
>>
>> Unless we wait until the script has finished before running the
>> synchronous section, no source at all will be selected
>
> Because changes to the set of <source> elements do not restart the
> resource selection algorithm, right? Why don't they, exactly? That
> seems broken to me, from the POV of how the rest of the DOM generally
> works (except as required by backward compatibility considerations)...
The resource selection is only started once, typically when the src
attribute is set (by parser or script) or when the first source element is
inserted. If it ends up in step 21 waiting, inserting another source
element may cause it to continue at step 22.
Restarting the algorithm on any modification of source elements would mean
retrying sources that have previously failed due to network errors or
incorrect MIME type again and again, wasting network resources. Instead,
the algorithm just keeps it state and waits for more source elements to
try.
>> However, as long as the same is true in all browsers this seems
>> easy to fix in the script itself, just a bit non-obvious.
>
> But why are we purposefully introducing hysteresis into the DOM? It'd
> make a lot more sense to me to not have hysteresis here if at all
> possible.
I'm not sure what you mean by hysteresis, but guess you mean the somewhat
ridiculous amount of state one has to keep track of? I think the root
cause of this is that if a source fails due to network errors (i.e.
asynchronously after the resource selection algorithm has returned) then
we want to try the next one. If we threw this out the window, then one
could define the algorithm in such a way that it only needs to be run
synchronously once and then be done. I could live with such a solution,
but I don't think it's the best one.
>> I'm trying to come up with a big scary problem that would motivate the
>> complexity of "await a stable state", but I can't see it. I doubt
>> StackOverflow would be flooded by issues caused by quirks as the one
>> above.
>
> It actually probably would, if if we actually had such a quirk.
OK, let's not debate this point :)
>> 1. Remove the "await a stable state" concept and just continue running
>> the steps that follow it. (This is what Opera does now when resource
>> selection is triggered by the parser, as I have no idea how long to wait
>> otherwise.)
>
> I have a really hard time believing that you trigger resource selection
> when the <video> is inserted into the document and don't retrigger it
> afterward, given that... do you?
>
>> 2. Instead of calling the resource fetch algorithm in step 5/9
>
> There doesn't seem to be such a step...
>
>> 3. In step 21, instead of waiting forever, just return and let inserting
>> a source element cause it to continue at step 22.
>
> Again, the numbering seems to be off.
These are steps in the resource selection algorithm, not in the resource
fetch algorithm.
>> Since this doesn't introduce any new concepts to the spec, I assume it
>> would be implementable in Gecko?
>
> Given the premise, presumably. But the resulting behavior still seems
> broken in the parser case; see above....
No, in the parser case I am very confident that it will work just fine, as
this is almost exactly what we already do. It's only in the case of
scripts that there's a risk of introducing new quirks. However, at this
point it's likely that some scripts are already doing things in the
"wrong" order, so perhaps it's too late to make the change I am suggesting.
Mozilla is implementing this now. How are you interpreting "await a stable
state" when the resource selection algorithm is triggered by the parser?
Will the result be 100% predictable or depend on "random" things like how
much data the parser already has available from the network?
--
Philip J?genstedt
Core Developer
Opera Software
Received on Tuesday, 10 August 2010 01:40:39 UTC