Re: [File API] feedback on August 1/5 draft

On Wed, 12 Aug 2009 17:13:57 +0200, Arun Ranganathan <arun@mozilla.com> wrote:
> Latest draft is:  
> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html

Thanks Arun!


> Anne van Kesteren wrote:
>> I have not received any feedback on my comments as to why getAsDataURL  
>> is actually needed. I still think it should be dropped.
>
> The rationale submitted by Jonas seems to be sufficient. [1]

Yeah. Come to think of it though, it needs to be specified on File rather than FileData. For a data URL you need the media type and that is only available from File (and does not make sense for all of FileData).


>> I think getAsURL() should become an attribute instead. E.g.
>>
>>   readonly attribute DOMString localURL;
>>
>> Since it is just a reference there is no need this needs to be  
>> asynchronous and there is also no need for it to be method.
>
> Done.

I think this also should only be available on File.


>> The constants of FileError need to be actually placed on the FileError  
>> object and renumbered as to make sense. They are not DOM exceptions so  
>> it does not make sense to align with that in any way.
>
> They are placed on the FileError object now, but have not been  
> renumbered.  Additionally, slice is now spec'd to throw a FileException.
>
> I'm not tightly wed to keeping the numbers the same as DOMException, but  
> honestly reusing SECURITY_ERR and NOT_FOUND_ERR from DOMException seems  
> desirable.  SECURITY_ERR is used by XHR as well, so keeping these  
> consistent (since File API will probably used in conjunction with XHR)  
> also seems desirable.  I also agree that simply using a meaningful  
> constant name is also useful, but kept the numbers the same for  
> consistency.
>
> Aside from numbering, I don't think there's a big difference between  
> FileError / FileException and SQLError/SQLException (or MediaError,  
> etc.).  Do you feel very strongly about renumbering?

Not strongly no, but if we just want to reuse DOMException here isn't that what we should do rather than have FileException?

Also, CANCEL_ERR should be renamed to ABORT_ERR to be in line with XMLHttpRequest / Web DOM Core.


>> The filedata URI scheme should allow the use of fragment identifiers on  
>> the resource. Also, I think we should drop the // from the scheme. I do  
>> not see why that is needed here.
>
> I've dropped the "//", but haven't spec'd the scheme to allow fragment  
> identifiers on the resource.  Could give me a use case?

If you can store and open documents I imagine you can view them inside <iframe> as well and it would make sense if you could set fragment identifiers of such a resource to scroll within them.

SVG couples special semantics to the fragment identifier for image/svg+xml resources. If the user selects an SVG resource an application might want to use such fragment identifiers.


>> Last time I also made comments regarding the details of discovering the  
>> encoding of a file etc. Those still seem to apply.
>
> Anne, I thought that even my past draft addressed most of them, with one  
> exception!  These comments seem to have been:
>
>  * 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.
>
> --> It is clear, but only iff. implementations cannot determine a  
> decoding to use.  You've said that the "left to implementations" part is  
> unacceptable, but that actually seems desirable, and they MUST use UTF-8  
> if they cannot determine the decoding.  Since they must fall back on  
> UTF-8, is this not sufficient?

Yeah, though I'd replace "encoding is in UTF-8" with "encoding is UTF-8".


>  * However, wouldn't it be better to use e.g. XML rules for XML files  
> and HTML rules for HTML files?
>
> --> The File interface has a mediaType attribute.  I reasoned that by  
> determining the mediaType, callers can determine which rules to use, or  
> at least determine whether they can use the filedata: scheme to surface  
> the content, etc.  Would you like me to make explicit statements about  
> XML/HTML, or is this sufficient?

I think it should be explicit if we want implementations to use XML/HTML rules to determine the character encoding when the media type of the file matches.


>  * 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.
>
> --> I specify that user agents can make a determination, and assumed  
> this as the case.  I can make this more explicit in a subsequent draft,  
> and look at responseText rules.  This is probably the only thing not  
> fully addressed, unless you have further nits on how I've addressed your  
> other nits.

I'd like it all to be explicit, but if I'm the only one I'm willing to concede on this.


By the way, you have written "mediatype" rather than "media type" twice.


> [1]  
> http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0511.html


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

Received on Wednesday, 12 August 2009 15:48:23 UTC