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

Anne van Kesteren wrote:
> 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 agree with this.
>
>   
>>> 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.
>
>   
This would probably be fine, although for filedata: URLs, we don't 
*need* a mediaType (we could just define octet stream or something on 
slice'd FileData objects).

I'm ok with moving it, thought.
> Not strongly no, but if we just want to reuse DOMException here isn't that what we should do rather than have FileException?
>   
Possibly, but I was thinking of having slice throw exception.SLICE_ERR 
if the range mathematics is wrong.  It probably won't need to throw for 
any other reasons.
> Also, CANCEL_ERR should be renamed to ABORT_ERR to be in line with XMLHttpRequest / Web DOM Core.
>   
Agreed!
>
>   
>>> 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.
>
>
>   
Agreed, I'll  add this to my ToDos for FileAPI.
> Yeah, though I'd replace "encoding is in UTF-8" with "encoding is UTF-8".
>   
OK
> 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.
>
>   
OK
>
> By the way, you have written "mediatype" rather than "media type" twice.
>
>   
I'll fix this.

-- A*

Received on Thursday, 13 August 2009 00:03:14 UTC