03 апр. 2013 г., в 13:11, Arun Ranganathan <[email protected]> написал(а):
>> 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.
What specifies how a File gets its type? The only requirement I can find is
that "User agents must not attempt heuristic determination of type", which I
think implies that something like inputElement.files[0].type is always "" for a
file chosen by a user via <input type=file>.
Guessing MIME type from file name or metadata is always a heuristic, as not all
platforms will know that "archive.sit" means "application/x-stuffit".
At the same time, browsers do autodetect types for many files. We'll need to
autodetect when serializing a form for submission anyway, so exposing this
information a little earlier only makes sense.
I think that these concerns can be resolved by specifying what File.type is
more explicitly. The spec can just say that parameters are not allowed in the
browser chosen type.
>> 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?
I do not have a very strong opinion. I like the simpler API of passing
parameters through the type attribute, as it's specified currently. This also
matches XMLHttpRequest API better. And of course, keeping existing behavior
means that we won't break the web.
- WBR, Alexey Proskuryakov
