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*
