- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Wed, 15 Jul 2015 10:43:38 +1200
- 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> 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