File API Feedback

It's really great that this is finally moving forward! Here are some preliminary comments on the current draft:

  http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml

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.

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.

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.

getAsDataURI() is better named getAsDataURL() for consistency with e.g. CSS url(), <canvas> toDataURL(), and <input type=url>. (Maybe just getText() and getDataURL()?)

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.
 * However, wouldn't it be better to use e.g. XML rules for XML files and HTML rules for HTML files?
 * 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.
 * 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".

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.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Thursday, 18 June 2009 17:53:08 UTC