Anne van Kesteren wrote:
I would prefer it if fileName and fileSize were simply named name and size
instead. It should be clear from the object what they mean.
OK.
I think it would be better if the FileError object was not modeled after the
DOMException interface. Making it consistent with how SQL errors are handled in
Web Storage seems better for consistency.
OK.
fileName is encoded as a DOMString and is therefore not in UTF-8 but 16-bit
code units. Omitting the encoding information would suffice I think.
OK
getAsDataURI() is better named getAsDataURL() for consistency with e.g. CSS url(),
<canvas> toDataURL(), and <input type=url>. (Maybe just getText() and
getDataURL()?)
OK
Comments on getAsText():
* I assume it is meant that if the encoding parameter is not provided UTF-8 is
used for decoding the file. I think that should be made more clear.
Yes -- and it should be made clearer.
* However, wouldn't it be better to use e.g. XML rules for XML files and HTML
rules for HTML files?
This is a good suggestion.
* It would also make sense to observe any BOM the file might have and maybe
information provided by the platform? Rules similar to how responseText for
XMLHttpRequest is computed could be used here I think.
OK
* It should also define how to deal with bytes it cannot decode with the given encoding.
E.g. replace them with U+FFFD as done elsewhere in the "Platform".
OK
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 want The Platform to have an alternative. I *also*
agree that CSS + working on input type=file multiple ...> are good
approaches, but don't agree that we should block on solving the problem
that way.
I absolutely agree that security issues are critical. I'm interested in
hearing from others about this, but I envision some *normative*
statements about errors, and some non-normative statements for UAs
(along the lines of what I've posted already).
Also, I hope to have another version of the specification (cleaned up
with everyone's nits that I acknowledge) for circulation next week by
Wednesday.
-- A*
