[whatwg] Remove addCueRange/removeCueRanges

[Philip Jägenstedt]

On Fri, 14 Aug 2009 12:48:59 +0200, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:

> On Fri, Aug 14, 2009 at 7:54 PM, Dr. Markus Walther<walther at svox.com>  
> wrote:
>>
>>
>> Silvia Pfeiffer wrote:
>>> 2009/8/14 Dr. Markus Walther <walther at svox.com>:
>>>> Hi,
>>>>
>>>>> The .start/.end properties were dropped in favor of media fragments,
>>>>> which the Media Fragments Working Group is producing a spec for.
>>>> Who decided this? Has this decision been made public on this list?
>>>>
>>>>> It will
>>>>> be something like http://www.example.com/movie.mov#t=12.33,21.16
>>>> var audioObject = new Audio();
>>>> audioObject.src
>>>> ='data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBAAAAABAAEAIlYAAESsAAACABAAZGF0Yf7///8AAAAA....';
>>>> // play entire audio
>>>> audioObject.play();
>>>> // play (0.54328,0.72636) media fragment
>>>> ?????
>>>
>>> Not in this way. In fact, the new way will be much much simpler and
>>> does not require javascript.
>>
>> With the code snippet given I was pointing out that it is not obvious
>> (to me at least) how the proposed media fragment solution covers data
>> URIs. If it is not meant to cover them, it is limited in a way that the
>> solution it seeks to replace is not.
>
> I see no reason why they should not be applicable to data URIs when it
> is obvious that the data URI is a media file. This has not yet been
> discussed, but would be an obvious use case.
>
> BTW: Did the start and end attribute implementations that you refer to
> cover the "data" scheme, too?

To my knowledge/experience, there is nothing special about data URIs. Any  
differences in how they work with the DOM interface or media fragments are  
more than likely implementation bugs.

-- 
Philip Jägenstedt
Opera Software