- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Tue, 14 Jul 2015 13:15:01 +1200
- 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 guarantees HAVE_CURRENT_DATA, HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA will be 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.) 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 01:15:45 UTC