- From: Glenn Maynard <glenn@zewt.org>
- Date: Sat, 16 Feb 2013 13:43:08 -0600
- To: robert@ocallahan.org
- Cc: whatwg <whatwg@lists.whatwg.org>
On Fri, Feb 15, 2013 at 2:10 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > On Sat, Feb 16, 2013 at 3:46 AM, Glenn Maynard <glenn@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
Received on Saturday, 16 February 2013 19:43:34 UTC