Re: [whatwg] video preload implementation feedback
On Fri, 15 Jun 2012 18:01:09 +0200, Ian Hickson i...@hixie.ch wrote: When preload=none, step 2 of http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-media-load-resource should not be optional. The effective (internal) preload state should be defined. It should also be defined that with preload=metadata, readyState should never go beyond HAVE_CURRENT_DATA, even for a data: URL or otherwise fully cached resource. Please specify the above. Making it non-conforming for a user agent to aggressively cache resources, especially if the user has asked for it, is a non-starter. Aggressively caching does not necessarily need to be exposed to scripts. There are going to be cases where that's what the user wants, and I don't see why we would have to make this non-conforming. As far as I can tell, the spec is as detailed as it can be here given the range of possible implementation strategies that we need to allow. Could you give a concrete example of what you are concerned about? video src=x preload=none onsuspend=makeSiteWork()/video Then we should stop firing suspend in the preload=none case, No. or fire it in every case if preload=non, even if the UA immediately unsuspends. Maybe. But I'm not convinced anyone is going to hook into onsuspend in this way. There'd be no point as far as I can tell, and it's more complicated than the alternative (just run the code straight away without waiting). You're not convinced that people on the Web do things in ways more complicated and fragile than necessary, just because it's possible? -- Simon Pieters Opera Software
Re: [whatwg] video preload implementation feedback
On Thu, 14 Jun 2012 20:32:16 +0200, Ian Hickson i...@hixie.ch wrote: On Thu, 14 Jun 2012, Simon Pieters wrote: It's not more. But it still is. Even though images aren't required to load at all, you still recently changed the way they load to be compatible (http://html5.org/r/7128 ). We should also specify how videos load to be compatible. We can do it now and get everyone to align on a good behavior, or we can wait and do it in a few years when Web content relies on what the market leader does, whether that's good or bad behavior. I don't understand what behaviour it is that you think we should define. When preload=none, step 2 of http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-media-load-resource should not be optional. The effective (internal) preload state should be defined. It should also be defined that with preload=metadata, readyState should never go beyond HAVE_CURRENT_DATA, even for a data: URL or otherwise fully cached resource. As far as I can tell, the spec is as detailed as it can be here given the range of possible implementation strategies that we need to allow. Could you give a concrete example of what you are concerned about? video src=x preload=none onsuspend=makeSiteWork()/video -- Simon Pieters Opera Software
Re: [whatwg] video preload implementation feedback
On Fri, 15 Jun 2012, Simon Pieters wrote: On Thu, 14 Jun 2012 20:32:16 +0200, Ian Hickson i...@hixie.ch wrote: On Thu, 14 Jun 2012, Simon Pieters wrote: It's not more. But it still is. Even though images aren't required to load at all, you still recently changed the way they load to be compatible (http://html5.org/r/7128 ). We should also specify how videos load to be compatible. We can do it now and get everyone to align on a good behavior, or we can wait and do it in a few years when Web content relies on what the market leader does, whether that's good or bad behavior. I don't understand what behaviour it is that you think we should define. When preload=none, step 2 of http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-media-load-resource should not be optional. The effective (internal) preload state should be defined. It should also be defined that with preload=metadata, readyState should never go beyond HAVE_CURRENT_DATA, even for a data: URL or otherwise fully cached resource. Making it non-conforming for a user agent to aggressively cache resources, especially if the user has asked for it, is a non-starter. There are going to be cases where that's what the user wants, and I don't see why we would have to make this non-conforming. As far as I can tell, the spec is as detailed as it can be here given the range of possible implementation strategies that we need to allow. Could you give a concrete example of what you are concerned about? video src=x preload=none onsuspend=makeSiteWork()/video Then we should stop firing suspend in the preload=none case, or fire it in every case if preload=non, even if the UA immediately unsuspends. But I'm not convinced anyone is going to hook into onsuspend in this way. There'd be no point as far as I can tell, and it's more complicated than the alternative (just run the code straight away without waiting). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video preload implementation feedback
On Thu, 14 Jun 2012 00:57:29 +0200, Ian Hickson i...@hixie.ch wrote: On Wed, 9 May 2012, Simon Pieters wrote: On Tue, 08 May 2012 18:59:29 +0200, Ian Hickson i...@hixie.ch wrote: On Thu, 18 Aug 2011, Philip Jägenstedt wrote: This is true, but as long as a few big browsers implement e.g. preload=none in a somewhat compatible way, it's hard to imagine page authors not coming to depend on that behavior so that it becomes required for web compat. It would be interesting to know if there are counter-examples, any script-visible behavior that is allowed to vary greatly between implementations without causing scripts to break. Images aren't required to load at all. Scripts aren't required to run at all. The window size is allowed to be any dimension at all. CSS isn't required to be supported at all. Users are allowed to apply arbitrary user style sheets. Users are allowed to interact with form controls by using the keyboard or the mouse or any other input device. All of these do break some pages. That CSS is optional and that users are allowed to apply user style sheets didn't stop you from specifying the Rendering section in great detail. Optional detail. UAs aren't required to follow that section. Making video behavior underdefined just because users should be able to disable video loading in preferences just means that in a few years the behavior of the market leader needs to be reverse engineered and implemented by everyone else. I do not understand how this particular feature could end up in that state any more than the other features I list above. It's not more. But it still is. Even though images aren't required to load at all, you still recently changed the way they load to be compatible (http://html5.org/r/7128 ). We should also specify how videos load to be compatible. We can do it now and get everyone to align on a good behavior, or we can wait and do it in a few years when Web content relies on what the market leader does, whether that's good or bad behavior. -- Simon Pieters Opera Software
Re: [whatwg] video preload implementation feedback
On Thu, 14 Jun 2012, Simon Pieters wrote: It's not more. But it still is. Even though images aren't required to load at all, you still recently changed the way they load to be compatible (http://html5.org/r/7128 ). We should also specify how videos load to be compatible. We can do it now and get everyone to align on a good behavior, or we can wait and do it in a few years when Web content relies on what the market leader does, whether that's good or bad behavior. I don't understand what behaviour it is that you think we should define. As far as I can tell, the spec is as detailed as it can be here given the range of possible implementation strategies that we need to allow. Could you give a concrete example of what you are concerned about? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video preload implementation feedback
On Wed, 9 May 2012, Simon Pieters wrote: On Tue, 08 May 2012 18:59:29 +0200, Ian Hickson i...@hixie.ch wrote: On Thu, 18 Aug 2011, Philip Jägenstedt wrote: This is true, but as long as a few big browsers implement e.g. preload=none in a somewhat compatible way, it's hard to imagine page authors not coming to depend on that behavior so that it becomes required for web compat. It would be interesting to know if there are counter-examples, any script-visible behavior that is allowed to vary greatly between implementations without causing scripts to break. Images aren't required to load at all. Scripts aren't required to run at all. The window size is allowed to be any dimension at all. CSS isn't required to be supported at all. Users are allowed to apply arbitrary user style sheets. Users are allowed to interact with form controls by using the keyboard or the mouse or any other input device. All of these do break some pages. That CSS is optional and that users are allowed to apply user style sheets didn't stop you from specifying the Rendering section in great detail. Optional detail. UAs aren't required to follow that section. Making video behavior underdefined just because users should be able to disable video loading in preferences just means that in a few years the behavior of the market leader needs to be reverse engineered and implemented by everyone else. I do not understand how this particular feature could end up in that state any more than the other features I list above. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video preload implementation feedback
On Tue, 08 May 2012 18:59:29 +0200, Ian Hickson i...@hixie.ch wrote: On Thu, 18 Aug 2011, Philip Jägenstedt wrote: This is true, but as long as a few big browsers implement e.g. preload=none in a somewhat compatible way, it's hard to imagine page authors not coming to depend on that behavior so that it becomes required for web compat. It would be interesting to know if there are counter-examples, any script-visible behavior that is allowed to vary greatly between implementations without causing scripts to break. Images aren't required to load at all. Scripts aren't required to run at all. The window size is allowed to be any dimension at all. CSS isn't required to be supported at all. Users are allowed to apply arbitrary user style sheets. Users are allowed to interact with form controls by using the keyboard or the mouse or any other input device. All of these do break some pages. That CSS is optional and that users are allowed to apply user style sheets didn't stop you from specifying the Rendering section in great detail. Making video behavior underdefined just because users should be able to disable video loading in preferences just means that in a few years the behavior of the market leader needs to be reverse engineered and implemented by everyone else. -- Simon Pieters Opera Software
Re: [whatwg] video preload implementation feedback
On Wed, 17 Aug 2011, Philip Jägenstedt wrote: I'd very much like to see feedback from other implementors. Are you happy with treating autoplay and preload as just hints as in [4] or do you think that we should specify them in greater detail? (This does not preclude having user preferences to override the standardized defaults.) What _makes_ these attributes just hints _is_ that you can have user preferences that override the defaults. On Thu, 18 Aug 2011, Chris Pearce wrote: I think autoplay should not be treated as a hint, else it's can't be relied upon to work, and thus would be completely useless. I think it's imperative that users be able to disable all video playback. By definition, that means that not all videos are going to play. This means that autoplay can't be relied upon to work. I don't think that's a problem. There's plenty of examples of things like that in the spec. For example, several browsers don't render images at all except when requested to render them, and then only in a separate window, not inline. I would expect similar behaviour for video. The great thing about HTML is specifically that it is media-independent in this very manner, allowing different user agents to be agents of the user, not of the author, displaying the content in the manner most appropriate for the user. On Thu, 18 Aug 2011, Philip Jägenstedt wrote: I think that too much variation in how preload is implemented is also likely to give compat problems. In http://www.w3.org/Bugs/Public/show_bug.cgi?id=12596#c7 I have an example of what might break when pages inevitably assume that preload=none causes the loadedmetadata event to not be fired. I do not think that example is realistic, as discussed in the bug. On Fri, 19 Aug 2011, Chris Pearce wrote: On Thu, 18 Aug 2011, Philip Jägenstedt wrote: If you only allow the internal state to increase, don't you need to reset it at some point as well? Or is it impossible in your implementation to use preload=auto on one load and preload=metadata on the next due to this? Oops, that is impossible in our implementation. That's a bug! I'll fix that, thanks for pointing this out. I agree that it we should specify when the preload internal state is updated to prevent this bug in other implementations. Resetting the internal preload state inside the synchronous section of the resource selection algorithm as you suggest is sensible. I agree with you! There might not _be_ an internal preload state. I don't know how we can really specify this. I'm happy to add a note if that would help avoid bugs; let me know if you think that would help (ideally, also let me know what you think the note should say). On Thu, 18 Aug 2011, Philip Jägenstedt wrote: This is true, but as long as a few big browsers implement e.g. preload=none in a somewhat compatible way, it's hard to imagine page authors not coming to depend on that behavior so that it becomes required for web compat. It would be interesting to know if there are counter-examples, any script-visible behavior that is allowed to vary greatly between implementations without causing scripts to break. Images aren't required to load at all. Scripts aren't required to run at all. The window size is allowed to be any dimension at all. CSS isn't required to be supported at all. Users are allowed to apply arbitrary user style sheets. Users are allowed to interact with form controls by using the keyboard or the mouse or any other input device. All of these do break some pages. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video preload implementation feedback
On Thu, 18 Aug 2011 04:50:17 +0200, Chris Pearce cpea...@mozilla.com
wrote:
I implemented preload support in Firefox.
On 18/08/2011 3:44 a.m., Philip Jägenstedt wrote:
I'd very much like to see feedback from other implementors. Are you
happy with treating autoplay and preload as just hints as in [4] or
do you think that we should specify them in greater detail?
I think autoplay should not be treated as a hint, else it's can't be
relied upon to work, and thus would be completely useless.
Preload is a less critical; if it's not supported users will just end up
loading more data, which isn't too bad. Clients that care more about
bandwidth will probably be more likely to support it.
I think that too much variation in how preload is implemented is also
likely to give compat problems. In
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12596#c7 I have an example
of what might break when pages inevitably assume that preload=none
causes the loadedmetadata event to not be fired.
== Resetting internal preload state ==
Due to the above, it's necessary to reset the internal preload state at
some point. Otherwise, a script like this wouldn't work:
function setSource(url) {
var v = document.querySelector('video');
v.src = url;
v.preload = none;
v.onplay = function() { v.preload = autoplay; };
Did you mean |v.preload = auto;| here instead? or |v.autoplay =
true;|? It seems in this case the onplay handler would only happen if
the user pressed play on the controls or from script, so the preload
action be promoted to auto anyway since the resource is playing. I guess
that's what you're getting at with your point about preload internal
state promotion?
Oops, it should be v.preload = auto. Indeed this example is more
complicated than necessary. Promotion of the internal state due to user
interaction also needs to be reset in the resource selection algorithm, so
any time that a HTMLMediaElement is reused this is a problem.
}
If a previous resource was playing and preload was set to autoplay by
script, then we still want preload=none to apply to the new resource.
To solve this, we are resetting the internal preload state as part of
the resource selection algorithm, right before step 5 to fire the
loadstart event. There are various other places one could do this, but
we think it is important to do it in the async section so that the
order of setting .src and .preload does not matter.
Currently we update the internal preload action whenever the value of
the preload state changes, and we check it's not preload=none before
kicking off a new resource load (resource fetch algorithm step 2) and we
check it again when we reach loadedmetadata and suspend the load if it's
preload=metadata.
I think the preload=metadata case is implied by the spec, but having it
explicitly stated wouldn't hurt.
It sounds like we're applying preload=none at exactly the same point,
that's good!
If you only allow the internal state to increase, don't you need to reset
it at some point as well? Or is it impossible in your implementation to
use preload=auto on one load and preload=metadata on the next due to
this?
== video preload=none ==
It's not possible to specify exactly how much preload=metadata and
preload=auto buffers and when, but this is possible for
preload=none. This is what we do:
After step 1 of the source selection algorithm, if preload==none, set
networkState to IDLE, fire a suspend event and set the
delaying-the-load-event flag to false.
This is actually specified now in step 2 of the resource fetch algorithm
(this must have been added after we implemented @preload).
Right, this is the partially accepted resolution of
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12596
Doing this at step 1 of the resource selection algorithm means that if
you're loading from child source elements, and none of them have a
supported type, then you won't report the error until something calls
play() or load() explicitly.
Oops, I meant resource fetch algorithm and what I have implemented is
exactly what the spec says, except that it's unconditional and the
implementation-defined event is playing or seeking.
Thanks for your feedback!
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] video preload implementation feedback
On Thu, 18 Aug 2011 05:36:42 +0200, Bjartur Thorlacius svartma...@gmail.com wrote: Þann mið 17.ágú 2011 15:44, skrifaði Philip Jägenstedt: I'd very much like to see feedback from other implementors. Are you happy with treating autoplay and preload as just hints as in [4] or do you think that we should specify them in greater detail? (This does not preclude having user preferences to override the standardized defaults.) If an UA may ignore them, than them being honored can't be relied upon - rendering the default configuration a question of implementation (i.e. providing sane defaults for the user agent's target user base) but not of interoperability. This is true, but as long as a few big browsers implement e.g. preload=none in a somewhat compatible way, it's hard to imagine page authors not coming to depend on that behavior so that it becomes required for web compat. It would be interesting to know if there are counter-examples, any script-visible behavior that is allowed to vary greatly between implementations without causing scripts to break. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] video preload implementation feedback
On 19/08/2011 12:01 a.m., Philip Jägenstedt wrote: I think that too much variation in how preload is implemented is also likely to give compat problems. In http://www.w3.org/Bugs/Public/show_bug.cgi?id=12596#c7 I have an example of what might break when pages inevitably assume that preload=none causes the loadedmetadata event to not be fired. This seems a valid reason to change from should to must for preload. I agree. If you only allow the internal state to increase, don't you need to reset it at some point as well? Or is it impossible in your implementation to use preload=auto on one load and preload=metadata on the next due to this? Oops, that is impossible in our implementation. That's a bug! I'll fix that, thanks for pointing this out. I agree that it we should specify when the preload internal state is updated to prevent this bug in other implementations. Resetting the internal preload state inside the synchronous section of the resource selection algorithm as you suggest is sensible. I agree with you! Cheers, Chris Pearce.
Re: [whatwg] video preload implementation feedback
I implemented preload support in Firefox.
On 18/08/2011 3:44 a.m., Philip Jägenstedt wrote:
I'd very much like to see feedback from other implementors. Are you
happy with treating autoplay and preload as just hints as in [4] or
do you think that we should specify them in greater detail?
I think autoplay should not be treated as a hint, else it's can't be
relied upon to work, and thus would be completely useless.
Preload is a less critical; if it's not supported users will just end up
loading more data, which isn't too bad. Clients that care more about
bandwidth will probably be more likely to support it.
== Dynamically changing preload ==
It makes no sense for a script to change preload=auto to
preload=none. Going from preload=auto to preload=metadata isn't
nonsensical, but supporting it would allow authors to toggle it
continuously to work around buggy buffering behavior. I'd much rather
that buffering problems be fixed in the browser, so I don't want to
support this. Consequently, we only allow the internal preload states
to increase, not decrease. I understand that Mozilla has done the
same. Unless there are strong reasons not do, I think this should be
spec'd.
I agree.
== Resetting internal preload state ==
Due to the above, it's necessary to reset the internal preload state
at some point. Otherwise, a script like this wouldn't work:
function setSource(url) {
var v = document.querySelector('video');
v.src = url;
v.preload = none;
v.onplay = function() { v.preload = autoplay; };
Did you mean |v.preload = auto;| here instead? or |v.autoplay =
true;|? It seems in this case the onplay handler would only happen if
the user pressed play on the controls or from script, so the preload
action be promoted to auto anyway since the resource is playing. I guess
that's what you're getting at with your point about preload internal
state promotion?
}
If a previous resource was playing and preload was set to autoplay
by script, then we still want preload=none to apply to the new
resource. To solve this, we are resetting the internal preload state
as part of the resource selection algorithm, right before step 5 to
fire the loadstart event. There are various other places one could do
this, but we think it is important to do it in the async section so
that the order of setting .src and .preload does not matter.
Currently we update the internal preload action whenever the value of
the preload state changes, and we check it's not preload=none before
kicking off a new resource load (resource fetch algorithm step 2) and we
check it again when we reach loadedmetadata and suspend the load if it's
preload=metadata.
I think the preload=metadata case is implied by the spec, but having it
explicitly stated wouldn't hurt.
== video preload=none ==
It's not possible to specify exactly how much preload=metadata and
preload=auto buffers and when, but this is possible for
preload=none. This is what we do:
After step 1 of the source selection algorithm, if preload==none,
set networkState to IDLE, fire a suspend event and set the
delaying-the-load-event flag to false.
This is actually specified now in step 2 of the resource fetch algorithm
(this must have been added after we implemented @preload).
Doing this at step 1 of the resource selection algorithm means that if
you're loading from child source elements, and none of them have a
supported type, then you won't report the error until something calls
play() or load() explicitly.
Regards,
Chris Pearce.
Re: [whatwg] video preload implementation feedback
Þann mið 17.ágú 2011 15:44, skrifaði Philip Jägenstedt: I'd very much like to see feedback from other implementors. Are you happy with treating autoplay and preload as just hints as in [4] or do you think that we should specify them in greater detail? (This does not preclude having user preferences to override the standardized defaults.) If an UA may ignore them, than them being honored can't be relied upon - rendering the default configuration a question of implementation (i.e. providing sane defaults for the user agent's target user base) but not of interoperability.
