This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently the spec does not constrain the readyState values that can be observed for specific preload values. In bug 28921 we see one example of how Web pages can depend on a specific readyState-based event firing for a specific preload value, but the problem is more general than that. If a Web author wants to preload so that a specific readyState-based event fires, there is technically no way to achieve that. So I think it makes sense to define a preload value for each readyState, that guarantees the browser will keep trying to preload until that readyState is reached. Even with that we'll still have interoperability and reliability problems when browsers sometimes exceed the readyState that was requested. For example, if the preload attribute is set to a value indicating the browser should preload until HAVE_CURRENT_DATA is reached, it is very likely that the download will not be cut off until HAVE_FUTURE_DATA has also been reached. Authors might accidentally depend on the 'canplay' event firing, when under other conditions or other browsers, it might fail to fire. We can avoid this problem by restricting readyState from advancing beyond the "goal readyState" (unless downloading/playback is triggered by means other than "preload"). So here's my proposal: Define a per-media-element "goal readyState" which takes the same values as readyState plus a "none" value (the default). Define preload values 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.) While the autoplaying flag is true, the readyState of the element is limited to less than or equal to the goal readyState if the latter is not "none". (Note that the autoplaying flag value does not depend on the presence of the autoplay attribute.) Then bug 28921 could amend the above rules to say preload="none": the goal readyState is HAVE_NOTHING if the "load() has been called" flag is not set, or HAVE_METADATA if it is set.
Another piece of the puzzle, which I think would help particularly for bug 28921, is to specify the concept of "effective preload", roughly as such: Its initial value is "none". In the reset steps of the media element load algorithm, it is set to "auto" if the autoplay attribute is present, or the preload attribute state otherwise. When the preload attribute is modified, the effective preload is set to the new state if it is a higher state. When the autoplay attribute is added, the effective preload is set to "auto". When play() or load() (not the internal media element load algorithm!) are called or the seek algorithm is invoked, the effective preload is increased to "metadata" if it was previously "none". Then, just use the effective preload concept everywhere.
roc, if you have some spec text in mind for this we can try to work it out. A pull request on https://github.com/whatwg/html would be even better. I guess that the readyState clamping is the most important for compat and can be done separately.
https://github.com/whatwg/html/issues/4469