W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: [FileAPI] File.mediaType

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 16 Nov 2009 12:29:11 +0100
To: arun@mozilla.com
Cc: "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.u3hjixsb64w2qv@anne-van-kesterens-macbook.local>
On Fri, 13 Nov 2009 11:36:33 +0100, Arun Ranganathan <arun@mozilla.com>  
wrote:
> Anne van Kesteren wrote:
>> This should be a bit more exact as to how the mediaType is returned. I  
>> would prefer ASCII-lowercase.
>
> Done.

The current text says the string is ASCII-encoded. That's not true. It's  
in 16bit code points like any other DOMString.


>> Returning "application/octet-stream" rather than null also seems better  
>> if the type is not known. That way you do not have to type check. Other  
>> parts of the platform also handle "application/octet-stream" as unknown.
>
> It's been pointed out that user agents type check on files.  If the  
> mediaType is not known, users invoking the attribute can't do anything  
> useful with it, so null is better.  What are the use cases for using  
> application/octet-stream instead?

I guess not known might be useful. Can't we just make it the empty string  
then? I don't really see the need to return something other than a  
DOMString.


>> Also, maybe we should just call this type? File.type seems unambiguous  
>> enough.
>
> "mediaType" is more specific than "type".

But it is less consistent with <style>.type, <script>.type, <link>.type,  
etc. I'm not sure we use mediaType anywhere right now.


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Monday, 16 November 2009 11:29:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT