- From: David Levin <levin@google.com>
- Date: Fri, 15 Jan 2010 05:28:39 -0800
(Basically agreeing with Darin) The empty string is what I was thinking would be appropriate for this case. The file/blob spec, http://www.w3.org/TR/FileAPI/, already allows for an empty string if the mime type cannot be determined: User agents SHOULD return the MIME type of the file, if it is known. If implementations cannot determine the media type of the file, they MUST return empty string. dave On Fri, Jan 15, 2010 at 12:36 AM, Darin Fisher <darin at chromium.org> wrote: > On Thu, Jan 14, 2010 at 11:04 PM, Ian Hickson <ian at hixie.ch> wrote: > >> On Thu, 14 Jan 2010, Darin Fisher wrote: >> > On Thu, Jan 14, 2010 at 12:10 PM, David Levin <levin at google.com> wrote: >> > > >> > > It seems like it the method should be toBlob. >> > > >> > > > This doesn't address my concern that you won't know the mime type of >> > > > the blob returned. >> > > >> > > This makes a good case to move the "readonly attrbiute DOMString type" >> > > from File to Blob. >> > >> > I like this suggestion. It seems reasonable for a Blob, which is just a >> > handle to data, to have an associated media type. >> >> What type should a blob have if it is the result of slicing another file? >> >> > I had the same thought after sending this ;-) > > A slicing operation that changes the size of the file should probably clear > the type field or set it to application/octet-stream. Perhaps Blob.type > should be settable in some cases? > > -Darin > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100115/6e696715/attachment-0001.htm>
Received on Friday, 15 January 2010 05:28:39 UTC