[whatwg] Make the files attribute of the input element writable

[Fred Andrews]

> Date: Thu, 17 Jan 2013 20:45:59 +0000
> From: ian at hixie.ch
...
> > >> 1) This would make it possible to write JavaScript libraries that 
> > >> seamlessly scan the current page for <input type="file"> and add 
> > >> integration with Dropbox / Google Drive / Sky Drive etc. I claim that 
> > >> changing the <input> value is the easiest and most robust method of 
> > >> achieving this without requiring changes to the main application 
> > >> code. Asides from providing an easy path for developers to integrate 
> > >> online storage services into their apps, this change would make it 
> > >> easy to write bookmarklets / browser extensions that add this 
> > >> functionality to any Web application.
> > >
> > > It seems like this use case would be better handled by having the 
> > > sites offer an API to the browser, similar to Web Intents, for picking 
> > > a file. That way you wouldn't need to update each site -- every site 
> > > would support all the drive systems you use.
> > 
> > Yes, but that approach would require deeper application changes. I think 
> > that adding a couple of <script> tags next to an existing <input 
> > type="file"> is easier to implement.
> 
> On the one hand, we require every application that can read a file to 
> modify their code to support the "drive" providers, and we require the 
> drive providers to provide code to support this, and we need UA changes, 
> and we make it hard to competitors of drive-like products to compete 
> (since anyone popular enough to be included by the sites that support this 
> will have a network effect advantage).
> 
> On the other hand, we require only "drive" providers and user agents to 
> write code, and every site that reads files supports every provider that 
> implements the API, and there's no barrier to entry for competitors.
> 
> I think the second is _significantly_ better all around.

FWIW The second solution, of a 'web intents' style mechanism, might also
help users secure their data by allowing them to use trusted apps and to
even take advantage of 'drive' providers when Javascript is disabled.

The benefits might also be applicable to other input types, and how this
might be done is something I am exploring for the PUA CG:
http://lists.w3.org/Archives/Public/public-pua/2013Jan/0000.html

It would be useful for the browser to store the returned blob to allow serial
invocation of web intents before the final blob is submitted.  For example,
a user might source a file in from a camera then invoke a number of
processing apps before the image is submitted.

It would be useful to support other input element types, such as text boxes.
For example, rich editors for HTML or Wikimedia could be handled by apps
and the content returned to the input element.

It would be useful to support general multi-input and multi-output to input
elements for each web intents invocation.  For example consider an input
form with a delivery address - the user might use web intents to search
for a contact using a web app that accepts any already supplied inputs
and returns the required fields to fill the form elements.

 Declarative markup would allow this to work even within a page with
Javascript disabled or restricted, and the infrastructure might help
browsers offer invocation suggestions even when a webpage does
not have declarative support.  For example, if a user has chosen a
rich Wikimedia editor for textbox input on a particular web page
then the browser might make this an easier choice in future.

Such support would give the user more choice in the apps used for
common tasks within web pages.  It might gain support from businesses
wanting to market their own web apps as substitutes, while allowing
security conscience users to choose trusted apps.  It might negatively
impact businesses that gain from bundling the implementations of these
tasks and restricting user choice, but perhaps on the balance it might
be possible to win support given that there is some support for 'web
intents' style solutions.
 
cheers
Fred