[whatwg] Remove addCueRange/removeCueRanges

Philip Jägenstedt philipj at opera.com
Fri Aug 14 04:08:16 PDT 2009

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

More information about the whatwg mailing list