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 10:51:49 +0200
Message-ID: <CAMQvoCnAvDj1L_DGaQETebSv9zbxkMN3BHjqQ6ZBi20moBPiyw@mail.gmail.com>
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
> 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?

Received on Tuesday, 14 July 2015 08:52:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:34 UTC