Html: Attribute to suggest filename for image elements (<img filename> / <img download>)

Created on 31 May 2017 · 12Comments · Source: whatwg/html

Problem

Web content may produce dynamic image data (data: / blob:) that users may choose to save:

<img alt="Course Completion Certificate" src="data:image/png,…">

If users try to save this image in a few natural ways they get a poor suggested filename:

Drag and drop image to Desktop
"Save Image as..." context menu

Existing behavior across browsers:

Safari: Unknown.png
Chrome: download.png
Firefox: a Text Clipping for drag, or index.png for save dialog

Developers should be able to provide a suggested filename to improve this experience for users.

Proposal

Include a new filename attribute on <img> elements:

<img alt="… Certificate" src="data:image/png,…" filename="Certificate.png">

Corresponding IDL:

interface HTMLImageElement : HTMLElement {
    [Reflect] attribute DOMString filename;
}

You could imagine this working on content like <canvas draggable="true"> so perhaps directly on HTMLElement alongside the draggable property would be suitable as well.

It can be specified closely to <a download>:

The attribute may have a value; the value, if any, specifies the default file name that the author recommends for use in labeling the resource in a local file system. There are no restrictions on allowed values, but authors are cautioned that most file systems have limitations with regard to what punctuation is supported in file names, and user agents are likely to adjust file names accordingly."

Alternatives Considered

Alternate attribute names:
- download - unlike which primarily changes behavior to cause a download, in the case the content is already downloaded. Different semantics => different name

Extend data: / blob: URLs to embed other attributes, like a filename.

Not very future proof if other URLs come in the future that would also want this
Not friendly with either data or blob URLs given how they may be constructed
Potential to break existing data URL parsers in other programs / tools given the existing format

Partial Workarounds

All workarounds require JavaScript, whereas the suggestion above does not require it. Likewise, none of these solve all problems. Example discussion.

Dynamically create and click on an <a download>.
Send data to server, navigate to URL, respond with Content-Disposition:attachment
Chrome's non-standard DataTransfer "DownloadURL" drag and drop attribute

additioproposal needs concrete proposal img

Source

JosephPecoraro

👍25

Most helpful comment

This is an old suggestion, and I'm but a lowly web dev, but I'd love to see this implemented. My use case is with dynamically created images. While some are served straight through canvas elements, others are first converted to base64 data URIs in an img element in order to provide the plethora of options (copy link, e-mail, print, set as desktop, etc.) associated with them, but not with canvas elements*

The problem faced is already outlined - the default filename given appears nonsensical. There's a few possible existing solutions given but not detailed as to why they are cumbersome or insufficient.

Using a BLOB: As mentioned, browsers aren't respecting the filename. But even if fixed, this would only make it so that the image can be saved with a reasonable filename - sharing the image outside of the page would break as an external site would not know what the BLOB is referring to.
Using name=image.png in the mediatype: did not work in browsers tested
Wrapping the image in an a tag: While this offers a "save link as" with the sensible filename given with download, "save image as" still co-exists in context menus and other handlers, and continue to offer the nonsensical filename.
Using a serviceworker to rewrite the fetch request: Not only does this install a serviceworker for no other purposes, setting it up for dynamic content proved to be an exercise (in futility - but I largely blame my own lack of experience with serviceworkers for that).
Re-serve the data server-side: Because the filename taken looks no further than the filename part of filename?data=base64, possibly the smoothest experience - but fraught with issues as it requires server side processing, with either multiple server-side files or accepting any filename to internally redirect to the appropriate server side processing page, incurs a traffic hit on both the client and server ends, and may not play nice with third party websites that accept the base64 data URI, but not cross-domain locations.

When a user initially asked why images being saved through the context menu on desktop were being saved as "index" (actually, their localized version thereof), and I checked what I needed to add to give it a more appropriate filename, I was surprised to find there was no such feature.
I'm sure it isn't requested often, and is generally not a big deal (just give it a new name in the save dialog, right?), but it is one of those UX things that make a product just a tad more polished (suggest e.g. "projectname date.png" by default); while, no doubt, introducing a whole host of potential gotchas.

* to wit, such a feature as discussed here would also be applicable to canvas elements regardless of the draggable property, if I'm not mistaken.

Thank you for your consideration!

Undoundoundo on 20 Oct 2018

👍4

All 12 comments

cc @smfr @junov @vmpstr

zcorpan on 2 Jun 2017

WebKit is interested in implementing this.

othermaciej on 6 Jun 2017

This is an interesting case. I'm curious if implementers find this particular user-story high priority enough (and high-frequency enough) to want to take on the implementation burden. It sounds like WebKit does!

Note that for blob URLs, this should already be accomplishable using a File. Quick demo: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5233. It appears nobody implements this, but that's a quality of implementation issue...

Given that, I'd personally prefer extending data URLs somehow, or just saying that you should use blob URLs if this user story is important for you.

Regardless, I'll ping some Blink folks to see if they're interested in the problem statement, leaving the solution aside for now. @smaug----, any thoughts from Gecko?

domenic on 6 Jun 2017

filename doesn't sound too bad. Use of blob uris would be rather awkward.

smaug---- on 7 Jun 2017

The solution should be per <source> too, as the format may differ.

jakearchibald on 7 Jun 2017

Or per candidate URL? Do you want a different filename between URLs in srcset?

It would be possible to handle that by updating img.filename onload, and decide on filename from currentSrc. Annotating each <source> or each URL in a <picture> seems a bit annoying, but I dunno.

zcorpan on 13 Jun 2017

Per url in the srcset doesn't seem as important, as kitten.jpg should be fine for all of them. But in the case of <source> it could be kitten.jpg for one source and kitten.webp for another.

Updating img.filename dynamically would cover the use-case though.

jakearchibald on 13 Jun 2017

The problem faced is already outlined - the default filename given appears nonsensical. There's a few possible existing solutions given but not detailed as to why they are cumbersome or insufficient.

Using a BLOB: As mentioned, browsers aren't respecting the filename. But even if fixed, this would only make it so that the image can be saved with a reasonable filename - sharing the image outside of the page would break as an external site would not know what the BLOB is referring to.
Using name=image.png in the mediatype: did not work in browsers tested
Wrapping the image in an a tag: While this offers a "save link as" with the sensible filename given with download, "save image as" still co-exists in context menus and other handlers, and continue to offer the nonsensical filename.
Using a serviceworker to rewrite the fetch request: Not only does this install a serviceworker for no other purposes, setting it up for dynamic content proved to be an exercise (in futility - but I largely blame my own lack of experience with serviceworkers for that).
Re-serve the data server-side: Because the filename taken looks no further than the filename part of filename?data=base64, possibly the smoothest experience - but fraught with issues as it requires server side processing, with either multiple server-side files or accepting any filename to internally redirect to the appropriate server side processing page, incurs a traffic hit on both the client and server ends, and may not play nice with third party websites that accept the base64 data URI, but not cross-domain locations.

* to wit, such a feature as discussed here would also be applicable to canvas elements regardless of the draggable property, if I'm not mistaken.

Thank you for your consideration!

Undoundoundo on 20 Oct 2018

👍4

Another use case - this time for accessibility related use use of downloading individual SVG img symbols

https://github.com/mulberrysymbols/mulberry-symbols/blob/master/docs/README.md#downloading-individual-symbols

SteveALee on 15 Mar 2019

Given the initial set of comments I think the main thing holding this back is someone driving it. There'll need to be some (manual) tests and a change to the specification needs to be written and put up as a pull request.