Re: [whatwg] preload="metadata" elements don't necessarily fire "canplay"

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