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 11:00:11 +0200
Message-ID: <CAMQvoCnunNuot8ESq55gOnsCci_sVbeEz2M9=GooW7Qnb0_WdA@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>, Ian Hickson <ian@hixie.ch>
Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
On Tue, Jul 7, 2015 at 11:56 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Tue, Jul 7, 2015 at 9:41 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>>
>> Unsurprisingly, I like this, as it's basically what Presto did. However, I
>> think preload="metadata" should reach HAVE_CURRENT_DATA, because you do
>> want to decode the first frame. The naming mismatch is weird, but oh well.
>
>
> OK.
>
>>
>> > The question is, would Chrome(ium) be willing to implement that
>> > reasonably
>> > quickly? I'm not optimistic given the canplaythrough debacle...
>>
>> Do you have links to previous debacles, so that I can see what the
>> constraints are, or have been?
>
>
> The constraint just seems to be a lack of interest in fixing interop issues
> in this area:
> http://code.google.com/p/chromium/issues/detail?id=73609

Thanks for the link. It looks like some attempt was made to fix it on
the Chromium side (i.e. in the media framework, not HTMLMediaElement)
and that the effort was abandoned. A simple clamping of readyState in
HTMLMediaElement would presumably be quite simple to implement, and
would reveal if it's web compatible or not quite quickly.

Hixie, do you have the bandwidth to figure out a spec for this at this
point? If not, maybe roc and I could work it out in a spec bug and you
can review?

Philip
Received on Tuesday, 14 July 2015 09:00:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 14 July 2015 09:00:44 UTC