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

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

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 15 Jul 2015 10:43:38 +1200
Message-ID: <CAOp6jLZOOd0VBb54gGgHG0AGkkV=OgH+f_j=p7M4oZGBdbQhyQ@mail.gmail.com>
To: Philip J├Ągenstedt <philipj@opera.com>
Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
On Tue, Jul 14, 2015 at 11:24 PM, Philip J├Ągenstedt <philipj@opera.com>

> 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?

Our current policy, which is basically HAVE_ENOUGH_DATA on desktop and
HAVE_METADATA on mobile.

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.

Maybe that's overengineering.

I propose we leave 'auto' as-is for now until we have more data, and first
do the other work I mentioned.

Then a possible next step would be to determine how much preloading
preload="auto" must do for Web compatibility (i.e., which readyState it
must reach), and define preload="auto" to have that as the goal readyState,
*but* we could also say that it preloads as much data as possible given
browser-specific policy (while not actually advancing the readyState beyond
the goal readyState until the autoplaying flag is false).

lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
Received on Tuesday, 14 July 2015 22:44:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 14 July 2015 22:44:13 UTC