W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2014

Re: [whatwg] whatwg Digest, Vol 127, Issue 5

From: Brett Zamir <brettz9@yahoo.com>
Date: Mon, 03 Nov 2014 16:16:05 -0700
Message-ID: <54580CB5.6050004@yahoo.com>
To: whatwg@lists.whatwg.org
On 10/28/2014 12:06 PM, whatwg-request@lists.whatwg.org wrote:
> Date: Tue, 28 Oct 2014 17:33:02 +0000 (UTC)
> From: Ian Hickson<ian@hixie.ch>
> Subject: Re: [whatwg] Shared storage
> On Sat, 15 Feb 2014, Brett Zamir wrote:
>> >
>> >The desktop PC thankfully evolved into allowing third-party software
>> >which could create and edit files shareable by other third-party
>> >software which would have the same rights to do the same. The importance
>> >of this can hardly be overestimated.
>> >
>> >Yet today, on the web, there appears to be no standard way to create
>> >content in such an agnostic manner whereby users have full, built-in,
>> >locally-controlled portability of their data.
> Why can't you just do the same as used to be done? Download the resource
> locally ("save", using <a href download>), then upload it to the new site
> ("open", using <input type=file>)?

Yes, as mentioned by others, this can become a terrible user experience, 
and this is not to speak of user agent reasons.

Besides the added challenges mentioned by Katelyn Gadd when live updates 
occur on multiple instances of the file across different applications, 
there is also the even more common use case of a particular app being 
able to remember the files used previously and let the user access them 
without needing to remember their exact location in a hierarchy (though 
allowing a hierarchy is desirable to the user for flexibility in 

Such recall of, and access to, previously used files without repeated 
need for manual selection is commonly found in apps which use the likes 
of a "recent files" drop-down or, perhaps even more commonly, by a set 
of tabs which open with the last set of used files.

There is also the specific desirability for functionality to iterate 
through file names (or other shared data) so that apps can provide their 
own UI, perhaps filtered down by file type according to the types of 
files consumable by the app, such as an IDE project viewer which still 
allows the user to group files app-agnostically and where they wish 
along with other file types.

The ability to store files of different types within the same 
user-viewable and user-creatable folder is compelling because the user 
has freedom to group like content together even if the file types 
differ. A user might wish to store an email draft, a word processing 
file, and a set of images all in the same folder to keep track of them, 
even if a given web app might not utilize all of these types. While 
there are apps which aggregate data from different sources and then let 
the user tag them in such a manner as to mimic this functionality, this 
is again application-specific and not necessarily portable or as 
flexibly under user control as would be a shared and hierarchical file 
storage area.

Received on Monday, 3 November 2014 23:16:34 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:26 UTC