Re: [FileAPI] Questions on using Blobs for img src and a href

On Oct 3, 2013, at 6:35 PM, Brian Matthews (brmatthe) wrote:


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


This is an implementation issue that goes beyond the spec. (as others have remarked, this kind of thing falls under the purview of UI/UX, which web specifications rarely touch on meaningfully), but I think it is probably a useful informative comment that I'll add as part of "LC Commentary" changes.

I think you should file bugs on all browser projects that you'd like to see this kind of thing implemented in.  It's a useful feature for end-users.


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


OK, I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23450

I'm not fully convinced by other commentors on this listserv that we should use Content-Disposition as how to do this.  I think "how" Save As is implemented is a detail left to browsers, but I think the part of using file name is useful during Save As.


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


Yes, I agree!  https://www.w3.org/Bugs/Public/show_bug.cgi?id=23451

Thanks for your thoughtful LC commentary.

-- A*