Re: File API Feedback

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*

Received on Thursday, 18 June 2009 22:00:28 UTC