This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11602 - <video> define precisely how autoplay overrides preload
Summary: <video> define precisely how autoplay overrides preload
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-23 14:20 UTC by contributor
Modified: 2011-08-08 21:25 UTC (History)
6 users (show)

See Also:


Attachments

Description contributor 2010-12-23 14:20:37 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#loading-the-media-resource

Comment:
define precisely how autoplay overried preload

Posted from: 83.218.67.122
Comment 1 Philip Jägenstedt 2010-12-23 14:29:01 UTC
A spec note now says "Note: The autoplay attribute can override the preload attribute (since if the media plays, it naturally has to buffer first, regardless of the hint given by the preload attribute). Including both is not an error, however."

It should be defined precisely how autoplay and preload interact, assuming that the UA honors them both and they haven't been overridden by user preferences.

Specifically:

1. <video preload="none" autoplay>

This is a contradiction in terms. Should the video load at all? If it does, it must load to at least canplaythrough, as that's what triggers autoplay. I'd consider making this markup non-conforming, as clearly the author is confused. Even so, the behavior must be defined.

2. <video preload="metadata" autoplay>

Same issue as above, except it's unclear if the UA should load up to loadedmetadata or canplaythrough. Since metadata is the default preload state, this behavior is very important. Using autoplay implies that one must load to canplaythrough, so it's really a fourth internal state in addition to the 3 exposed preload states.

3. <video preload="metadata" oncanplaythrough="this.play()">

If adding the autoplay attribute influences the buffering behavior, should attaching event handlers do the same?
Comment 2 Philip Jägenstedt 2010-12-23 14:30:38 UTC
My preferred answer (implementation) would be to cause the autoplay attribute to imply a preload state between metadata and auto, the same state that would be used while the video is playing. I don't think attaching event handlers should have any influence.
Comment 3 Philip Jägenstedt 2011-01-05 16:33:52 UTC
(In reply to comment #1)
> 1. <video preload="none" autoplay>
> 
> This is a contradiction in terms. Should the video load at all? If it does, it
> must load to at least canplaythrough, as that's what triggers autoplay. I'd
> consider making this markup non-conforming, as clearly the author is confused.
> Even so, the behavior must be defined.

In this situation, Firefox 4.0b9pre behaves as if preload=auto had been given, suggesting that they simply take autoplay to imply preload=auto. No other browser tested seems to support preload=none at all.
Comment 4 Philip Jägenstedt 2011-01-15 21:12:32 UTC
What's going on, why was this moved to Web Performance/Test Suite? It's a bug filed against the HTML5 spec. Please move it back or explain.
Comment 5 Ian 'Hixie' Hickson 2011-06-02 23:36:13 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale:

The behaviour for preload="" is intentionally entirely undefined, it's a hint only.

The behaviour of buffering is intentionally mostly undefined, it's a quality of implementation issue.

The behaviour of autoplay="" is intentionally partially undefined, UAs can override it.

I don't see how I could possibly precisely define the interaction of these three issues. It would depend entirely on the implementation goals. For example, if the UA always ignored autoplay="" and preload="" and required the user to give explicit permission for every 10 bytes that were buffered, the answer regarding how they would interact would be radically different than if the UA ignored preload="", always buffered everything aggressively at the first possible opportunity, and autoplayed if the attribute was present. Most UAs will hopefully be in between these, but the situation is still that this is essentially intentionally undefined.

Having said that, if there is a specific question you had in mind, please let me know (and reopen this bug). I'm happy to add non-normative text that tries to give guidance on this.
Comment 6 Philip Jägenstedt 2011-06-09 12:41:24 UTC
I can perhaps live with the spec not defining if autoplay is equivalent to preload="metadadata", preload="auto" or something in between (or beyond), but it should definitely say what happens with the first example:

<video preload="none" autoplay>

Is autoplay considered only once preload > none, or does it override preload?

What I've implemented and want the spec to say is that if you use autoplay together with preload="none", it is as if preload="none" was not used at all. In other words, the video should autoplay, not wait until a script sets preload="metadata" or the user interacts with the controls to start loading.

Surely, this far there's no risk of being too specific and limiting what clever things implementors can do with the preload hint?
Comment 7 Michael[tm] Smith 2011-08-04 05:35:14 UTC
mass-move component to LC1
Comment 8 Ian 'Hixie' Hickson 2011-08-06 03:40:05 UTC
At least the following three behaviours are entirely intentionally allowed for the case of <video preload="none" autoplay>:

1. Immediately download the entire resource and play it back as soon as HAVE_ENOUGH.
2. Immediately download the entire resource but do not autoplay.
3. Download nothing until the user hits play.
4. Download only the metadata and then wait for the user to hit play.
5. Do nothing until the user presses a UA-provided button, at which point download ten bytes at a time and display them as a hexdump, prompting the user to confirm that those ten bytes are ok before adding them to the buffer, and not playing anything at all.

You can ignore preload, you can ignore autoplay, you can honour both or none. I don't really know what you want me to say here. They're both just hints.
Comment 9 Ian 'Hixie' Hickson 2011-08-08 21:25:08 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 8