- From: Arun Ranganathan <arun@mozilla.com>
- Date: Thu, 30 Oct 2014 02:55:03 -0400
- To: Web Applications Working Group WG <public-webapps@w3.org>
- Message-Id: <54DC7466-5D62-4B50-AF90-F44353BB22BF@mozilla.com>
WebAppsWG, At the recent F2F, I received an ACTION to strike one of the use cases from the File API, since the File API itself did not deliver on that use case. This is ACTION 750: https://www.w3.org/2008/webapps/track/actions/750 which asks me to remove the use case, since there isn’t a mechanism to trigger programmatic downloads to the underlying OS filesystem. But upon reflection, although FileAPI itself hasn’t provided any API surface for this, the recently finished HTML specification has given us something useful, but not implemented widely yet: http://www.w3.org/TR/html5/links.html#attr-hyperlink-download The use case itself calls for things such as storing assets for later use, including for use with third-party apps such as Calendar apps, which I’ve demonstrated using the Blob constructor and the “download” feature, since not everyone present at the meeting knew you could do this: http://aruner.net/resources/BlobURL/datePickerForCal.html In Firefox and Chrome (desktop) it works by triggering a download and invoking the Calendar application on your particular OS (Outlook 2013 on Windows or Calendar on Mac OS X). Safari shows the iCalendar entry “in the raw” and although Safari on iOS allows images that are Blob URLs to be downloaded, it doesn’t allow much to be done with other data types that are blob: URLs, such as iCalendar entries. I don’t think I should remove the use case, but instead said that the actual requirement was handled in HTML, even if implementation status isn’t at 100%. The File API provides additional guidance for File objects: http://dev.w3.org/2006/webapi/FileAPI/#processing-media-types — A*
Received on Thursday, 30 October 2014 06:55:41 UTC