[whatwg] Drag-and-drop feedback
dimich at google.com
Fri Feb 26 10:56:47 PST 2010
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:
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.
> 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).
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.
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
> 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
>> .getItem(n) = DataTransferItem
>> .add(stringData, type)
>> 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!
>> 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...
More information about the whatwg