W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2015

Re: [whatwg] preload="metadata" elements don't necessarily fire "canplay"

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 14 Jul 2015 13:13:49 +0200
Message-ID: <CAMQvoCnFQNd8gow9kJ6dsj0fgM9mi6WdM3_T-hSLeFLezgnzxQ@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
On Tue, Jul 14, 2015 at 1:08 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Tue, Jul 14, 2015 at 10:33 PM, Philip Jägenstedt <philipj@opera.com>
> wrote:
>>
>> I see, is this a policy that's applied even with a single <video> in a
>> page, or is it something like a limit on the total number of players
>> that can be created, or limits on how much stuff (decoders) they set
>> up internally? Presto actually had a limit on the number of players on
>> 32-bit systems, as one might otherwise run out of virtual memory with
>> just a few hundred <video> elements...
>
>
> There are various kinds of resource limits. The problem with those is that
> they're fragile and make behavior unpredictable.

Yeah, this is tricky, obviously no browser could successfully load a
million <video> elements up to readyState HAVE_ENOUGH_DATA
simultaneously, but making that fail in the same way cross-browser
seems like a big task.

If the behavior could be made interoperable for when resources are not
a problem, that would be a good start at least. The spec can say that
the browser should at least try to ready HAVE_ENOUGH_DATA for
preload="auto", to rule out artificial limits if any browser has them.

Philip
Received on Tuesday, 14 July 2015 11:14:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 14 July 2015 11:14:20 UTC