- From: Daniel Cheng <dcheng@google.com>
- Date: Mon, 29 Mar 2010 15:26:32 -0700
I like the DataTransferItems proposal. I had a few questions, but no one answered, so I'm going to propose some modifications: DataTransferItems is a mapping of types to data like DataTransfer. DataTransfer mirrors DataTransferItems, but DataTransfer.getData() will throw an error if the data is a blob. Maybe a second getData method that can provide conversion given a text encoding would be useful? DataTransfer changes: DataTransfer.addFile(fileData); dataTransfer.items = DataTransferItems DataTransferItems.length .getItem(type) = DataTransferItem .add(stringData, type) .add(blobData) .add(dataTransferItem) .clear() DataTransferItem.kind = 'string', 'blob' .type = MIME type .getTextData(function callback (data)) - throws if binary is true .getBlob() - returns Blob The binary property has been folded into the "kind" property. When interacting with non-DOM apps or pages, some platforms can't easily convert arbitrary MIME types to native data transfer types for copy/paste or DnD. For this reason, I think the spec should explicitly list MIME types for which UAs should handle the conversion to native data transfer types. A couple that come to mind: text/plain, text/uri-list, text/rtf, application/rtf, text/html, text/xml, image/png, and image/svg+xml. UAs can make a best-effort attempt to convert the other types, but it won't be guaranteed that they will be there for interaction with non-DOM applications. Daniel On Tue, Mar 9, 2010 at 3:03 PM, Daniel Cheng <dcheng at google.com> wrote: > On Fri, Feb 26, 2010 at 10:56 AM, Dmitry Titov <dimich at google.com> wrote: > >> On Mon, Feb 22, 2010 at 6:06 PM, Daniel Cheng <dcheng at google.com> wrote: >> >>> Several questions about the proposal: >>> How does DataTransferItems interact with the original DataTransfer >>> object? I'm assuming changes in one should be reflected in the other. If >>> that's the case, what should happen if I do this: >>> dataTransfer.items.add(fileData); >>> dataTransfer.getData(mimeTypeForFile); >>> >> >> Unless there is a specific reason to think different, there is only one >> set of items backing DataTransfer object - today the files and 'other items' >> are represented separtely, the proposed items list is simply a merged >> version of the same. In your example you should be able to getData. >> > > Does that mean getData() can return types besides DOMString? > > >> >> >>> How come there's no DataTransferItems.get(type) method? >>> >> >> There can be multiple items of that type (dragging several image files). >> Would it return another items list? What is the use case for this? Also, >> some items may have empty type (a file with unknown extension). >> > > I think files have always been a special case and should continue to be > handled that way. I don't think there's any platform pasteboard that > supports multiple items of one non-file type, so it'd make the most sense to > make it a 1:1 mapping from types to data. > > >> >> DataTransferItem provides richer metadata than is available through the >>> native drag-and-drop interface on most platforms. When dragging data from a >>> non-DOM application, how do you extrapolate the metadata to fill in the >>> type/binary fields? >>> >> >> 'type' can be inferred in many cases from file extension, native clipboard >> format or other means. It can be done w/o content sniffing and disk IO. >> > > Should there be some sort of standard list of mappings that all UAs should > support wherever possible? What happens if the UA doesn't have a mapping for > a type? > > >> >> I understand 'binary' as indicator of whether or not the item can be read >> as a text string. I'm not sure why item.kind == "string" is not the same. If >> the intent is to also cover some files that can be read as string and as >> Blob, then it might be buggy because the only way to establish if the file >> can be converted into JS string is to actually read the bytes and try to >> convert to Unicode. There can be invalid character sequences or the encoding >> info may be missing. >> >> Perhaps we should remove 'binary' and assume that items that item.kind == >> "string" can use getTextData(callback) to pull the string. >> >> On a separate note, I think items.add(dataTransferItem) is not useful w/o >> a way to create a new DataTransferItem separately from the DataTransferItems >> list. >> >> >>> >>> Daniel >>> >>> >>> On Mon, Feb 22, 2010 at 3:51 PM, Ian Hickson <ian at hixie.ch> wrote: >>> >>>> On Thu, 4 Feb 2010, Ian Hickson wrote: >>>> > On Sat, 23 Jan 2010, Eduard Pascual wrote: >>>> > > >>>> > > Would it be possible to provide a list of "drag items" (to call them >>>> > > somehow) instead of, or in addition to, the current info provided by >>>> > > the DataTransfer object? >>>> > >>>> > That's a pretty good idea. I think we should probably do this when we >>>> > add more types to the DataTransfer object. >>>> >>>> Some engineers at Google discussed this a bit and came up with the >>>> following proposal: >>>> >>>> dataTransfer.items = DataTransferItems >>>> >>>> DataTransferItems.length >>>> .getItem(n) = DataTransferItem >>>> .add(stringData, type) >>>> .add(blobData) >>>> .add(fileData) >>>> .add(dataTransferItem) >>>> .clear() >>>> >>>> DataTransferItem.kind = 'string', 'file', 'blob', ... >>>> .type = MIME type >>>> .binary = boolean >>>> .getTextData(function callback (data)) - throws if >>>> binary is true >>>> .getBlob() - returns File or Blob >>>> >>>> When we add promises later, this can easily be extended to support that >>>> as >>>> well (basically, just by adding a new add() method for the promise >>>> case). >>>> >>>> I've put this into the comment in the spec, but haven't specced it. If >>>> any >>>> browser vendors want to try implementing this or something like it, any >>>> reports of implementation experience would be very useful. Please prefix >>>> the "items" attribute with some unique string like "webkitItems" or >>>> "geckoItems" so that it doesn't clash with the spec when we do add >>>> something like this! >>>> >>>> Cheers, >>>> -- >>>> Ian Hickson U+1047E )\._.,--....,'``. fL >>>> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ >>>> ,. >>>> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100329/59a0a6a6/attachment-0001.htm>
Received on Monday, 29 March 2010 15:26:32 UTC