[whatwg] <video preload> implementation feedback

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'