[whatwg] video tag : loop for ever

[Jonas Sicking]

>>>  After thinking about this, I'm not sure that limiting playback to a
>>> section of a media file will be used very often. A developer can easily
>>> script the same functionality as long as they don't use the default
>>> controller, so it seems to me that attributes for this aren't warranted.
>> I think they are useful if you want to:
>>
>> a) Loop a fragment (might be useful for audio for the same reason people
>> chop up a single large image to use multiple background images)
> 
> Does having a boolean loop attribute (also included in the DOM)
> satisfy your needs?
> 
> 
>> b) Use the default controls and get the right behavior. This is pretty
>> important, I don't think we should require writing a full custom set of
>> media controls just to be able to play a fragment without getting clearly
>> bogus UI.
> 
> I think controlling a video or audio player requires a decent
> javascript API. Mabye we are still lacking in that respect. But I
> don't think start and end should be a feature of html elements,
> because if they are mainly used for dynamic stuff, they are not well
> expressed as attributes.

It sounds to me like there are 3 proposals:

1. Have 'start' and 'end' as content attributes. This means that they
    are accessible though getAttribute/setAttribute and <video start=...
    end=...> in the markup).
    They are also available as DOM attributes, i.e. myVideo.start = ...
    myVideo.end = ...

2. Allow a fragment identifier to be specified in the src that specifies
    a part of the file to be played.
    Expose DOM attributes to control the start and the end, i.e.
    myVideo.start = ..., myVideo.end = ...
    Setting these attributes would change the value of the fragment
    identifier in the src attribute and thus which part is being played

3. Allow a fragment identifier to be specified in the src that specifies
    a part of the file to be played.
    Don't expose myVideo.start or myVideo.end DOM attributes. Instead
    address the use case of having multiple sound effects in a single
    downloaded file in some other way (for example using zip files,
    playlists, or simply letting people set the fragment identifier
    manually using the src attribute)


There is also the somewhat orthogonal issue of if the default UI should 
only display the selected range (be it if the selection happens through 
content start/end attributes or a fragment identifier).

I would personally be fine with all three proposals. The risk with 
proposals 1 and 2 that I see is that a implementation might be expected 
to download the whole file even if just part of it is specified to be 
played so that transitions can happen rapidly.

/ Jonas