Re: File API: Blob.type

On Mar 19, 2013, at 8:52 PM, Glenn Maynard wrote:

> On Tue, Mar 19, 2013 at 1:41 PM, Arun Ranganathan <arun@mozilla.com> wrote: 
> 
> > 2.    Convert every character in relativeContentType to lower case.
> 
> I recommend referencing "Converting a string to ASCII lowercase" in HTML.  http://www.whatwg.org/specs/web-apps/current-work/#converted-to-ascii-lowercase


Done.

> 
> > 1.    If relativeContentType contains any non-ASCII characters, then set relativeContentType to the empty string and return from these substeps.
> > 3.    If relativeContentType contains any line break characters like "CR" or "LF" or any CTLs or separators, then set relativeContentType to the empty string and return from these substeps.
> 
> #3 is too vague.  I recommend combining #1 and #3, saying: "If any character in relativeContentType outside of the range U+0020 to U+007E".  That's the printable ASCII range, and excludes all control characters.
> 


Done (+ thanks).


> > 4.    Parse relativeContentType as an RFC2616 media-type, tokenizing it according to the ABNF for media-type [RFC2616] with the ASCII "/" character separating tokens representing the type and subtype productions. If relativeContentType cannot be tokenized according to the ABNF for media-type [RFC2616], then set relativeContentType to the empty string and return from these substeps.
> 
> I'm not sure we should be this strict.  I'd lean towards keeping it simple, allowing any string at all as long as it contains only lowercase, printable ASCII.


Done -- we restrict it now, but don't mandate tokenization along the lines of RFC2616.


> You don't need to say "The following requirements are normative for this parameter".  That's what the normative language that follows ("must") means.


Done.


> My only concern is that blob.type should never contain parameters.  Comparing it to "text/plain" or "image/jpeg" should work, and not mysteriously fail a year later when somebody eventually throws a MIME type parameter into the mix.  Today, all browsers expose text files at text/plain.  If a browser a year from now decides to call text files with a UTF-8 BOM "text/plain; charset=UTF-8", it'll break interop.
> 
> Additionally, determining a blob's file type seems like the most obvious use of this property, and making people say "if(blob.type.split(";")[0] == 'text/plain')" is simply not a good interface.


OK -- you're strongly opinionated on the matter of NOT allowing a charset parameter.  I'd like to see if implementers who had an opinion on its usefulness can weigh in -- Darin?  Alexey?

http://dev.w3.org/2006/webapi/FileAPI/

-- A*