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: Wed, 15 Jul 2015 15:59:57 +0200
Message-ID: <CAMQvoCnGKAXtKg2gF=uEJg1Tt8RmZKA03AE_97dy+pYaFqdgog@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
On Wed, Jul 15, 2015 at 12:43 AM, Robert O'Callahan
<robert@ocallahan.org> wrote:
> 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.

Does this mean that you don't decode the first frame on mobile? Do all
formats really have reliable data about the video size without
attempting to decode a frame?

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

OK, I take it the most important bit for you is in the title of this
thread: preload="metadata" elements don't necessarily fire "canplay".

I'd be quite happy to see preload="metadata" spec'd with a requirement
to never go beyond readyState HAVE_CURRENT_DATA, except when the
effective preload state is changed by the autoplay attribute, play()
or setting currentTime. Spec'ing that concept of effective preload
would also be great, I assume it's been implemented in multiple
engines.

I've added some telemetry to Blink to see how common an explicit
preload="metadata" is compared to no explicit preload, to get some
kind of idea about the risk.

Next steps?

Philip
Received on Wednesday, 15 July 2015 14:00:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 15 July 2015 14:00:33 UTC