Firefox already does this and Opera is going to as well. The spec certainly allows it, but in an attempt to not specify the exact buffering behavior doesn't say precisely when preload=none kicks in and the suspend event is fired. In Opera it's going to be checked in the resource fetch algorithm, just after step 1. If preload==none at this point, networkState is set to NETWORK_IDLE, a suspend event is fired and the "delaying the load event" flag is set to false.

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: Partially Accepted
Change Description: see diff given below
Rationale: I've allowed it more explicitly, but since 'preload' can be completely ignored (it's just a hint) I haven't required the link from preload=none to suspend being fired.

Checked in as WHATWG revision r6352.
Check-in comment: Explicitly allow 'suspend' before 'fetch' (for preload=none in particular).
http://html5.org/tools/web-apps-tracker?from=6351&to=6352

Can you give an example where preload=none would be taken as hint and overruled by the browser? The "hinty" nature of metadata/auto is rather obvious, much less so with none.

mass-move component to LC1

In a Web browser, if the user has set a pref saying that "prefetch" should always be ignored and all media should always be immediately downloaded. Or suppose search engines ran scripts, one could have a search engine indexer that always downloads every resource that it finds. Or consider a browser optimised for users with a visual impairment that reads out the text under the user's finger, and wants to quickly play back the few seconds of a <video> around the playhead when the user drags his finger over it. It needs to preload at least a little even if preload=none.

It seems extremely unlikely that this is actually going to work. As soon as a few major browsers have implemented preload="none" as not downloading anything initially, people will write scripts like this:

<video preload=none src=video.webm></video>
<script>
var v = document.querySelector('video');
v.onclick = function() {
  v.onloadedmetadata = function() {
    // create UI using v.duration
  };
  v.play();
};
</script>

Any browser that fires the loadedmetadata event for preload=none will simply not work. Will you be willing to spec this when it becomes requires for web compat?

(In reply to comment #6)
> Or
> suppose search engines ran scripts, one could have a search engine indexer that
> always downloads every resource that it finds.

A search engine that wants to index all media elements can just download and inspect them, it doesn't need to do so using a browser engine. In fact, if it wants to generate screenshots and index subtitles it *cannot* do it using a browser engine due to cross-origin policy.

> Or consider a browser optimised
> for users with a visual impairment that reads out the text under the user's
> finger, and wants to quickly play back the few seconds of a <video> around the
> playhead when the user drags his finger over it. It needs to preload at least a
> little even if preload=none.

This is pretty much the same situation as a user simply deciding to play a video, in which case it will start buffering. This will cause scripts to break if they don't expect that the user can play/pause a video that doesn't have (native or scripted) controls, but I don't think there's anything the spec can do about that.

(In reply to comment #7)
> 
> <video preload=none src=video.webm></video>
> <script>
> var v = document.querySelector('video');
> v.onclick = function() {
>   v.onloadedmetadata = function() {
>     // create UI using v.duration
>   };
>   v.play();
> };
> </script>

This wouldn't work anyway. Why would "onclick" ever fire?

(In reply to comment #8)
> 
> A search engine that wants to index all media elements can just download and
> inspect them, it doesn't need to do so using a browser engine. 

It does if it wants to find the video resources embedded by script.


> This is pretty much the same situation as a user simply deciding to play a
> video, in which case it will start buffering. This will cause scripts to break
> if they don't expect that the user can play/pause a video that doesn't have
> (native or scripted) controls, but I don't think there's anything the spec can
> do about that.

Every <video> can have (and indeed should have) native controls, even those that don't have the controls="" attribute. (If there's no controls="" attribute, the controls will likely be in a context menu, rather than on-screen controls.) The API is designed specifically to make it easy to create controllers in script that interact with the browsers' native controls coherently. This allows the user to still access advanced controls (e.g. playback rate, captioning) even if the page doesn't provide full controls.


(Please reopen the bug if you respond, as I will not see comments otherwise unless I happen to look at the bug for unrelated reasons.)

(In reply to comment #9)
> (In reply to comment #7)
> > 
> > <video preload=none src=video.webm></video>
> > <script>
> > var v = document.querySelector('video');
> > v.onclick = function() {
> >   v.onloadedmetadata = function() {
> >     // create UI using v.duration
> >   };
> >   v.play();
> > };
> > </script>
> 
> This wouldn't work anyway. Why would "onclick" ever fire?

It fires when the user clicks the video:

<video src=video.webm preload=none poster="playbutton.png"></video>

The above script will break if the video has begun buffering before the video is clicked. Obviously, this can break for other reasons as well, but it's hard to see how the preload=none behavior could *not* become required for web compat. Waiting with spec'ing it until that has happened means that we can't actually pick a solution, we'll have to go with whatever some major browser decided on in the absence of a proper spec.

> (In reply to comment #8)
> > 
> > A search engine that wants to index all media elements can just download and
> > inspect them, it doesn't need to do so using a browser engine. 
> 
> It does if it wants to find the video resources embedded by script.

Yes, but it can't actually index the video itself using a browser engine due to the cross-origin policy. If it's a modified browser engine in violation of the spec, I don't see how it's relevant to the discussion.

> > This wouldn't work anyway. Why would "onclick" ever fire?
> 
> It fires when the user clicks the video

Why would the user click the video? The UA might just start playing the video when the user selects "play video" from the menu bar, or might start it when the user says "start video" out loud, etc.


> The above script will break if the video has begun buffering before the video
> is clicked.

The above script will break in any number of ways because it makes a fundamentally flawed assumption.


> > > A search engine that wants to index all media elements can just download and
> > > inspect them, it doesn't need to do so using a browser engine. 
> > 
> > It does if it wants to find the video resources embedded by script.
> 
> Yes, but it can't actually index the video itself using a browser engine due to
> the cross-origin policy.

The script can't, but the indexer can. The indexer is the "browser engine" in this context. It just wants the URLs. If a page is chaining videos one after the other, a search engine that uses scripts would want to start each video it comes across to see what happens when it gets to the end, for instance.


suspend="" is a hint. I don't really see how else it can be.

(In reply to comment #11)
> suspend="" is a hint. I don't really see how else it can be.

This is the web. Authors make stupid assumptions. We need behavior to be consistent where at all possible in order for sites to not break in some browsers because they only tested in one browser. It's surprising to have to explain this to you, Hixie. :-)

It's not that simple. There are plenty of things on the Web where we can't guarantee interop. Are you saying we should define what each pixel of an <input type=range> should look like? Or whether images display, regardless of whether the user wants to disable images? Or what font size should be used, regardless of whether the user is using a braille display, a handheld device, or a projector displaying the Web page on a 50m wall? We don't define when documents get evicted from the bfcache, or what the network bandwidth must be. We don't require browsers to autoplay videos. And we don't require that browsers download videos or not download videos when the page loads.

There is no point in requiring that 'suspend' fire if preload=none if the browser _does_ preload _anyway_. That would just make the event be a lie.

I think preload=none is more similar to plugins not loading when <object> is not in a document. You could argue that a browser might want to load such plugins, but the Web depends on them not loading. Philip and I expect the Web will depend on preload=none also not loading. Whether that happens remains to be seen, of course.

If you're saying there are use cases for a way to entirely disable a video element, so that user agents aren't even allowed to let the user start playback, then we could certainly consider such a thing, either a disabled="" attribute maybe, or something like preload="disabled" which would be a much stronger hint (and would be non-conforming when used with controls=""), or maybe preload=none but only when it's not in the Document, or some such.

But preload=none is designed to be just a hint, and it doesn't prevent the user from starting the video when the video is in the Document, so it doesn't make sense to me that we would treat it as anything but a hint.

zcorpan, foolip: clarification as to whether the use case in comment 15 is what you have in mind would be helpful in determining what to do here. (Ideally, if that is a satisfactory solution, please file a new bug for it so that we can track it separately rather than mutating this bug.)

No, it's not what we have in mind. The user should be able to play the video.

It seems we can't come to an agreement here. Resolving as NEEDSINFO, pending real-world data demonstrating the issue one way or the other.