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

Hi Brian,

Responses inline.

On Fri, Oct 4, 2013 at 6:35 AM, Brian Matthews (brmatthe) <
brmatthe@cisco.com> wrote:

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

I think that the first is an implementation bug.  The second is more
complicated.


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

For instance, there's nothing in the spec requiring browsers to display
URIs on hover at all.  This is kind of a tricky UI problem (data URIs have
similar issues).  Browsers probably want to show that clicking the link
goes somewhere, but the URI doesn't provide any useful information to the
user.

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

If a File object (which has a name) is used instead of a Blob I think we
should treat it as if something like "Content-Disposition: filename=$
file.name" was specified in an HTTP request.  I don't know if browsers
support Content-Disposition without inline/attachment specified.  This is
the sort of thing that would be appropriate to put in the spec.

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

I don't think we want to introduce yet another way to parse URIs (which is
what treating '/' as special for blob would do).

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

I suspect this is just not implemented yet.

- Kyle