Re: [File API] Blob.slice()

On Wed, 31 Aug 2011 06:17:17 +0200, Arun Ranganathan <>  
> On 8/14/11 5:42 AM, Anne van Kesteren wrote:
>> Why does the slice() method use [TreatUndefinedAs=EmptyString]? Can it  
>> not just use the normal default handling? Also, if you do indeed want  
>> to use that saying "If the contentType parameter is undefined, let  
>> relativeContentType be set to the empty string." in the text is  
>> redundant and ought to be removed.
> Default handling doesn't treat undefined as the empty string AFAICT.

Indeed. Why is the default handling not acceptable? TreatUndefinedAs seems  
more for legacy APIs, not new ones.

> The redundancy is instructive.

Redundancy with the IDL is avoided in all specifications I know of. I  
think it should be here too.

>> The slice() method definition does not state what happens when the  
>> contentType parameter is neither the empty string nor a valid media  
>> type.
> I'm not sure we need to mention this.  Developers can do things with  
> this argument that could cause their Blob objects to be handled weirdly  
> by downstream APIs (e.g. "foo-baz/bas").  I'm really not sure what  
> exactly we can say here; I can put in a warning or note.

You need to say what user agents have to do when developers set it to  
"trala la" or some such. "foo/bar" is still a valid media type, "foo=bar"  
is not.

>> The definition of the slice() method is also very confusing with  
>> several MUST statements. I think it would be better if it were defined  
>> as a single algorithm in line with how we normally define methods.
> It's defined as a single algorithm:
> and cribs from ECMAScript's definition of slice.  It's the only host  
> object with a slice.

It still looks like several independent algorithms to me. There should be  
one that includes processing of the arguments.

Anne van Kesteren

Received on Wednesday, 31 August 2011 08:48:49 UTC