Robin,
- The indentation of your WebIDL snippets is a bit broken, which
makes them hard to read.
I've got this nit numerous times; I'm going to fix it.
- Do we want to keep FileList? I think we're all tired of those. I
know that the sequence<T> section of WebIDL hasn't been written, but
this could be a good way of encouraging Cameron :) I'd personally be
all for killing that interface and just using sequence<File>.
I discussed this on #whatwg. Definitely, the sequence<T> syntax is much
more elegant, but it isn't ready yet.
I think FileList's existence primarily as an [IndexGetter] for File
doesn't hurt too much.
- FileAsText is poorly named IMHO, I had to reparse the description
of getAsDataURI several times before I realised that it used
FileAsText (which on quick read was immediately classified as "for
getAsText"). How about just FileContent?
Agreed.
- It might be useful if the FileAsText (or FileContent) callback got
a second argument telling it what kind of data it's getting (in this
case "text" or "dataUri"). No strong feelings on this, just a thought
I'm putting out there.
I actually want to rework this based on other feedback obtained in IRC
(about having FileData as separate from File). I'll circulate that for
review.
- There's some lexicographic confusion around URI/URL (for a
change). Data URLs are called, well Data URLs (as per RFC 2397) and
it's also the terminology you use in the prose. Yet the method is
called getAsDataURI. Consistency wouldn't hurt, I don't really care
which way.
Agreed.
- Suggestion: how about having a mediaType attribute on File? The
system usually knows such things (I believe) and it could be useful
for scripts to decide what to do based on what users have picked, or
to correctly label the file when interacting with a service (e.g. DAV).
Hmm.. the proposal which I received via IRC was to split what is now
"File" into FileData (everything *but* name) and File (name), with File
inheriting from FileData. Perhaps mediaType could go with File.
- Flash doesn't ask permission to show the file picker, but it
requires genuine interaction (as of F10 you can't trigger it without
interacting with Flash content).
Yes. I've made permission solicitation a MAY pending further discussion
with UAs.
- For FileListDataCallback what happens if the user cancels? Do I
get an error? A defined but empty FileList? I have a slight preference
for the latter, but either way the author should be notified.
I should make this clearer, but currently if the user cancels, the
FileErrorCallback will be called with FileError (with errorCode
SECURITY_ERR). Subsequent suggestions from Anne to NOT match what
DOMException does might mean cleaning up my error codes and adding some
new ones.
- General note on asynchronous calls: instead of void, should they
return an opaque token which can be used to cancel the request (or
provide one way or another of doing that, possibly just having
cancel() on the object)? That's available on setTimeout/setInterval,
and on XHR — it's generally useful.
Having cancel() on *what objects* exactly? Also, WindowTimer may not be
the best example.
- How do you propose to handle encoding errors? Say a file is UTF8
and I request it as ASCII? Drop what can't be converted? Use a
replacement character? Throw an error?
In my opinion, charset conversion shouldn't throw any errors, but should
try to honor the call as best as possible. I'll make this clearer.
All of these are good nits -- thank you!
-- A*
