W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2013

Re: [whatwg] Assigning media resources represented as DOM objects to a media element

From: Robert O'Callahan <robert@ocallahan.org>
Date: Mon, 18 Feb 2013 10:25:51 +1300
Message-ID: <CAOp6jLZhBfchM1zzrfYWvifoYicVQ1kOYdE4EEA+zW_jrQ-Jzg@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: whatwg <whatwg@lists.whatwg.org>
On Sun, Feb 17, 2013 at 8:43 AM, Glenn Maynard <glenn@zewt.org> wrote:

> On Fri, Feb 15, 2013 at 2:10 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
> Even if you get past that, you still have the problem that revoked URLs
>> are useless. It's impossible to do something equivalent to video2.src =
>> video1.src (which works today).
>>
>
> True, though cloneNode() should definitely work.  On the other hand,
> .innerHTML works with blob URLs if the URL is still in scope, but would
> never work here (not something I use often, but I guess some people still
> do).
>

cloneNode() won't work for autorevoked URLs, because it is defined to only
clone attributes and children, not internal state (with a few exceptions
for Web compatibility). (Don't tell me that it shouldn't work that way; I
argued that long ago and lost :-).) innerHTML-based cloning would work in
the same cases cloneNode() would: i.e. not at all for autorevoked URLs or
srcObject.


>  Also, getting access to the underlying source object is a valuable
>> feature, especially for MediaStream and MediaSource objects which have
>> interesting APIs on them.
>>
>
> I don't know anything about those, but you can always stash a reference to
> an object on the img, even if img doesn't care about it.  "img.src =
> URL.createBlobURL(blob); img.xActualBlob = blob;"  It's not as nice as
> having them tied together, but it's not terrible.
>

Yes, you can work around not having an API for this, if you control both
the setting and the getting. It's still a workaround.

I think the stakes are not that high here. Lack of srcObject can be worked
around in most cases. On the other hand adding srcObject is not a big
burden --- I don't think it needs to be added to every resource-loading
element. It's useful for media elements, maybe <img>, and dubiously
<iframe> (all of which already have multiple ways to specify the resource
to load).

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
Received on Sunday, 17 February 2013 21:26:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:19 UTC