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

On Tue, Jul 14, 2015 at 11:24 PM, Philip Jägenstedt <philipj@opera.com>
wrote:

> 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).

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn

Received on Tuesday, 14 July 2015 22:44:11 UTC