[whatwg] a rel=attachment

[Glenn Maynard]

2011/7/15 Ian Fette (イアンフェッティ) <ifette at google.com>

> I really don't see the importance of the "name the thing that isn't going
> to be downloaded" usecase; there are countless edge cases that we could
> concern ourselves with in HTML but that few users will ever hit, this is
> one.
>

A common case is generated PDFs, which are regularly both saved to disk and
viewed in-browser (eg. tax forms which are viewed to print and then saved
for records).

 (I also suspect a user sophisticated enough to actually save something,
> e.g. right click save as, is sophisticated enough to be able to type their
> own filename.)
>

As a user sophisticated enough to enter a filename, I still want the browser
to do it for me.  "The user can do it by hand" isn't an argument for
requiring them to.

You don't always need to "right click save as", either.  For example, a user
with no browser PDF support will generally receive a window like Firefox's
"open with/save as" prompt, which should also be able to use this as a hint,
without forcing users *with* browser PDF support to save to disk.
Similarly, dragging to the desktop, dragging into other applications, batch
downloading (eg. via DownThemAll), and so on.

I think it's better overall to keep the semantics as clean and simple as
> possible.
>

I don't think combining orthogonal concepts is clean or simple.  It seems
like a step back from Content-Disposition, where these concepts are already
cleanly separated.

(Sorry for pressing this point, since I don't feel extremely strongly about
it, but I just felt these arguments against it were a bit weak.)


2011/7/15 Darin Fisher <darin at chromium.org>:
> URLs (that are not backed by a single file).  This is valuable to me
because
> I can imagine wanting to save the contents of a <canvas>, and that
probably
> involves saving the data URL that you get from toDataURL().

You'd probably want Canvas.toBlob and FileSaver for this, once both are
implemented.

-- 
Glenn Maynard