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, 14 Jul 2015 13:15:01 +1200
Message-ID: <CAOp6jLb8Pz0CdXWD97YcBL3V05C6-jPNkJ9ujrjH10WkzGgXTg@mail.gmail.com>
To: Philip J├Ągenstedt <philipj@opera.com>
Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
Apart from the problems already discussed here, there is currently no
specced or interoperably implemented way to set a preload value that
reached ... "auto" may do one of those things, but it doesn't have to, and
in fact on mobile Firefox we don't guarantee any of those things.

So I suggest we revamp preload as follows:
preload="none": the goal readyState is HAVE_NOTHING.
preload="loadedmetadata": the goal readyState is HAVE_METADATA.
preload="metadata": the goal readyState is HAVE_METADATA (or some higher
value if needed for Web compatbility).
preload="loadeddata": the goal readyState is HAVE_CURRENT_DATA.
preload="canplay": the goal readyState is HAVE_FUTURE_DATA.
preload="canplaythrough": the goal readyState is HAVE_ENOUGH_DATA.
(Thus the expectation for authors is that if you set preload="X" then event
X will eventually fire.)

I would spec that while the autoplaying flag is true, the readyState of the
element is limited to less than or equal to the goal readyState if there is
one. (Note that the autoplaying flag value does not depend on the presence
of the autoplay attribute.)

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, 14 July 2015 01:15:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 14 July 2015 01:15:46 UTC