[whatwg] a rel=attachment

[Darin Fisher]

On Thu, Jul 14, 2011 at 1:53 PM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/14 Darin Fisher <darin at chromium.org>
>
>> I know that there is also a proposal to add a FileSaver API.  I like that
>> as well, _but_ it is very nice to be able to simply decorate an anchor tag.
>>  In many cases, that will be a lot simpler for developers than using
>> JavaScript to construct a FileSaver.  I think it makes sense to implement
>> both.
>>
>
> FileSaver is useful in its own right, but it's not a great fit for this.
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031398.html
>
> That reminds me of something download=filename can't do: assign a filename
> while leaving it inline, so "save as" and other operations can have a
> specified filename.  That would require two separate properties.  One case
> I've come across is <img>, where I want to display an image, but provide a
> different filename for save-as.  Separating the filename would allow this to
> be applied generically both links and inline resources: <img
> src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg filename=picture.jpg>.
>
> In that case, rel=enclosure would probably make sense.
>

Yeah, that makes a lot of sense.  I'm fine with using rel=enclosure too.


>
> On the other thread, Michal Zalewski raised a concern about giving
>> client-side JS the power to name files.
>>
>
> That subthread just seemed to be asking whether browsers should implement
> Content-Disposition, which didn't seem relevant--they already have, for
> years.
>
> Separately, there was a security question raised about the ability to serve
> a file off of a third-party site with a different filename than was
> intended.  For example, uploading a file which is both an executable trojan
> and a valid JPEG to an image hosting site, and linking to it externally,
> overriding its filename to .EXE.  The question there isn't about being able
> to serve executables--you can always do that--but being able to serve
> executables that appear to be from the image hosting site.  Arguably, it
> could 1: cause users to trust the file because it appears to be from a site
> they recognize, or 2: cause the site to be blamed for the trojan.
>
> I mention it so people don't have to scour the previous threads for it, but
> I think it's uncompelling.  It just seems like something UI designers would
> need to take into consideration.  (In my opinion, the trust and blame for
> saving a file to disk should be applied to the host *linking* the file, and
> not from the site hosting the file, which makes the above irrelevant.)
>
>
Agreed.  I suspect that users will associate a download with whatever host
they see in the location bar.

-Darin