- From: Michael A. Puls II <shadow2531@gmail.com>
- Date: Wed, 24 Feb 2010 05:58:17 -0500
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: uri@w3.org
On Wed, 24 Feb 2010 05:34:55 -0500, Julian Reschke <julian.reschke@gmx.de> wrote: > On 24.02.2010 08:04, Michael A. Puls II wrote: >> I have a web page that's meant to run locally via file:. It uses XHR to >> load a vcard file. I then scan the file and convert it to a different >> text file format. >> >> I want to provide a save link for the new file format, so I decided to >> use a data URI. But, I want clicking on the data URI link to show an >> open/save dialog. >> >> I was able to do this by using <a >> href="data:application/octetstream;charset=utf-8,file_data" >> target="_blank">Save</a>. >> >> However, there are 2 problems. >> >> 1. There doesn't seem to be a way to give a filename hint. >> >> 2. I'd rather not use the octetstream mime type just to trigger a save >> dialog. >> >> With that said, I think it'd be awesome if you could do something like: >> >> <a >> href="data:text/plain;charset=utf-8;filename=tada.txt;content-disposition=attachment,file_data">Save</a>. >> >> >> Setting aside the File API work, what about specifying those two in an >> update to the data URI RFC? Any vendors against implementing support for >> it? > > Sounds like a nice idea; a few thoughts: > > - Given the sad state of data URI parsing in UAs, it may be hard to > deploy this extension; did you make tests whether existing UAs properly > parse (== ignore) new parameters? I tested a little in Safari, Opera, Firefox and IE. The extra params don't seem to bother Firefox, Safari and Opera. I can't get data URIs to work at all in IE atm, so... However, I didn't test complex filename values and the different ways you can encode them. If I remember correctly, IE handles filename values differently than the RFC and other browsers. So, I suspect that IE will probably give the most trouble. Although, I'm sure I could find bugs in the other browsers too. But, I'm hopeful that it wouldn't be too hard for browsers to support. > - An alternative would to define a way to include arbitrary headers; so > that Content-Disposition could be used as defined (but this may get > messy) > > - It would be nice to align this with the current IETF work on > rephrasing RFC 2231 and RFC 2183 for use in HTTP... Thanks -- Michael
Received on Wednesday, 24 February 2010 10:58:45 UTC