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:24:20 +0200
Message-ID: <CAMQvoCmuSU=Lb-y5awXJO1c8c+8Q_okSov7EmtywCY2-FtZzig@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:17 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Tue, Jul 14, 2015 at 11:13 PM, Philip Jägenstedt <philipj@opera.com>
> wrote:
>> 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.
> If that behavior is required for Web compatibility, then we should do it.
> However I also think there's value in having a preload value that preloads
> aggressively on some platforms but not on others.

Basically a "I trust the browser to decide and promise not to assume
anything state"? The "auto" state is already suitable named and
defined for that, so if implementing "auto" as anything other than
"try to reach HAVE_ENOUGH_DATA" is in fact web compatible, a new state
for that might make sense.

Practically speaking, though, what would be the policy for "auto" that
differs between platforms, in the case of a single video element in a
page? If the different policies could be made explicit, it might be
nice to have explicit preload states for them and a way for scripts to
know the effective preload state.

Received on Tuesday, 14 July 2015 11:24:46 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:34 UTC