[whatwg] Drag-and-drop feedback
dcheng at google.com
Tue Mar 9 14:03:19 PST 2010
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:
> 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
> 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
>>> 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
>>> 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