- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 14 Jul 2015 10:51:49 +0200
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
On Tue, Jul 14, 2015 at 3:15 AM, Robert O'Callahan <robert@ocallahan.org> wrote: > 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.) Would it solve the same practical problems if "auto" were redefined to mean that the goal readyState is HAVE_ENOUGH_DATA? Is there a reason it doesn't do this in mobile Firefox? Philip
Received on Tuesday, 14 July 2015 08:52:16 UTC