Re: File API Feedback

Ian Hickson wrote:
> On Thu, 18 Jun 2009, Arun Ranganathan wrote:
>   
>>> I think FileDialog is a bad idea. We already have UI for selecting 
>>> multiple files: <input type=file multiple>. (And soon with 
>>> DataTransfer.files we have a second one.) I would much rather wait 
>>> with FileDialog until it is very clear that we need it. It seems to me 
>>> that <input type=file multiple>, the ability to expose files to 
>>> ECMAScript, and the ability to upload files asynchronously using 
>>> XMLHttpRequest is pretty much what applications are asking for. The 
>>> motivation for this feature seems therefore to be purely about UI, 
>>> which we should try to solve with CSS. There is no need to have 
>>> duplicate functionality here.
>>>       
>> Today, well-known web applications leverage Flash for uploading content, 
>> since what browsers do by default when prompted by <input 
>> type="file"...> isn't desirable to these applications (with few 
>> exceptions).
>>     
>
> I spoke with the developers of one of these Well-Known Web Applications, 
> and they didn't even _mention_ the styling difficulties of <input 
> type=file> as one of the reasons for using Flash here. 
This feedback is extremely useful.  I, too, would like the chance to 
speak with the developers of (that particular application) as well as 
with other developers.

Also:
> Local display of images before uploading them requires being able to take 
> a File object and poke it into parts of the platform that currently only 
> take URLs. I suggest that the way we address this is by adding an API to a 
> File object that returns a URL like this:
>
>    scheme:uuid
>
> ...where "scheme" is some new scheme, and uuid is some unique number. Each 
> URL in this scheme would have an intrinsic origin that is equal to the 
> origin of the script context (the "first script" in HTML5 terms) that 
> invoked the API to get the URL. This URL could then be passed around as a 
> string and would be treated as a resource from the same origin as that 
> script, and could thus be used with <img> and <canvas> and so on.
>
> This would just need a File.getAsURL() method that mints the URL and 
> returns it. The URLs would have some defined lifetime (e.g. same as the 
> Document, or same as the session, or same as the browser, or something).
>
>   
This was mentioned in IRC as well, and I broadly like the idea.  I don't 
mind spec'ing it out as well, but it does add a layer of complexity to 
what we've already got.  This isn't a use case for FileDialog and has 
nothing to do with input type=file either, however, and I'm keen to hear 
from others as well about FileDialog vs. solving this with better input 
type=file support.  Also, your discussions with that particular 
application vendor may have revealed a subset of requirements pertinent 
to them.  We *do* hear that styling is a major issue in feedback we've 
gathered so far, so I'm not ready to let the point go.

To be consistent with the FileData + File approach, getAsURL() might be 
something on FileData (and not File).

-- A*

Received on Thursday, 18 June 2009 23:02:19 UTC