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

[Glenn Maynard]

On Fri, Feb 15, 2013 at 2:10 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Sat, Feb 16, 2013 at 3:46 AM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> a) This isn't the case.  The tricky bit was defining precisely when
>> autorevocation happens; this has been resolved (the "global script clean-up
>> jobs list").  There's a remaining piece (
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765), but while it'll
>> take some thought to do that in a clean way (so it can be applied to
>> different APIs concisely), there's nothing magic there.
>>
>
> Serves me right for checking the latest published version instead of the
> real spec... Sorry.
>
> It may be that "there's nothing magic there", but in comment #17 Ian seems
> less than enthusiastic ("this is nuts, IMHO").
>

He didn't explain why it's nuts. (Putting aside the apparent
misunderstandings in comment #14, eg. "prose everywhere that might
eventually use part of a string as a URL", since I replied to that and he
didn't respond to my reply.)

Since we have a real URL parser now, I think we have a reasonable way to do
this: capture the blob in the parser, returning it as part of the parsed
URL.  Then, it becomes straightforward: if an APIs parses URLs
synchronously these URLs will work, and if they parse asynchronously then
they won't.

The XHR spec would just work, since it already parses URLs synchronously
from open().  HTMLImageElement.src and srcset would need to parse the URL
synchronously, rather than waiting for the "update the image data" to
happen.

If there are APIs that can't guarantee if they'll parse synchronously or
asynchronously, then it should tell the parser to never capture blobs, to
guarantee that they never work rather than being nondeterministic.

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).

 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.

-- 
Glenn Maynard