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: Tue, 7 Jul 2015 21:56:24 +1200
Message-ID: <CAOp6jLa2kOfuD44BXVgutdcKHg9=UN8Yx61Lp=moKHAvg1nyDA@mail.gmail.com>
To: Philip J├Ągenstedt <philipj@opera.com>
Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
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.


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

> Given that Blink's default preload state is
> auto that ought to limit the breakage somewhat, but I wouldn't really be
> surprised to find sites that use preload="metadata" and yet assume that
> canplay will fire, or similar.
> Whatever kind of mess we're in, it would be nice to aim for
> interoperability.


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, 7 July 2015 09:56:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 7 July 2015 09:56:59 UTC