I've been doing some prototyping around displaying images with <img src="blob:..."> and providing links to content using <a href="blob:...">. I've got it working, and it's all very cool, but there are a couple of things that seem like they could work better. They might be things that are too user agent specific for the spec (http://www.w3.org/TR/FileAPI/) to comment on, but I thought I'd ask here and see if there's something I'm missing, and make a suggestion.
First is the status bar display for anchors while hovering over them. As expected, it's the blob URL. While this is completely correct and exactly what I'd expect, I'm not sure how useful it is. For an anchor with a "normal" URL, the user is told something about where the resource is (the domain name and path, "http://example.com/order";), and what it is (the last element of the path, "invoice.pdf"). With a blob URL, they're told where it is (at least for those who know what a blob URL is, or accept that "blob:..." is something magic they don't need to know about :-) ), but nothing about what it is. Second, and related, is what happens when someone saves an image or target of a link. In both cases with "normal" URLs, there's a name component and the user agent can use that as the name of the resulting file, or suggest it if doing a Save As.... With blob URLs, there is no name, so the user agent has to make up a name. So with Firefox one gets fun names like index.gif (when saving an <img>), or bf_UK+0O.gif and y+f+wR9a.pdf (when saving the target of an anchor), and Chrome uses the opaqueString part of the URL, resulting in names like 49c122d8-0958-4dfd-ac9c-0a6245c5f91f.gif. None of those exactly brim with semantic content. While I might be (probably am) missing something, I don't think there's any work around for either. Even the standard onmouseover="window.status='map.gif'" for the first doesn't work in most (all?) browsers these days. Given that, my suggestion would be to promote the name attribute from the File interface to the Blob interface, and use it (if not null) when constructing blob URLs: blob:49c122d8-0958-4dfd-ac9c-0a6245c5f91f/map.gif. When using such a blob URL to locate the Blob in memory, the user agent would ignore everything after the first slash (just as it does with #, and presumably, although the standard doesn't, but probably should, state such, ?). When saving the contents of the Blob on the filesystem, the user agent would use the Blob's name as the file name, and when doing a Save As... type operation, would suggest the same as the file name. Or, as an alternative to promoting the name attribute, scripts could add the file names (as they can add fragment identifiers (and query strings?) today) to blob URLs and the user agent would take everything between the last unescaped / and first unescaped # or ? as the file name. Note that from the spec one would think I could do a new File(myBlob, myFilename), but both Firefox and Chrome throw exceptions when I do that (is that expected?), and if I use a "real" File (from a FileList), the name doesn't flow through to the blob URL and isn't used when saving. Thoughts? Also, 8.5.6 step 1 in the spec starts "Fire a progress event called error. Set the error attribute;". Doesn't firing an event call the event handlers immediately? If so, this seems to be saying to call the error handler *before* setting the error attribute, which seems backwards. Thanks, Brian
