- From: Trevor Burnham <trevorburnham@gmail.com>
- Date: Thu, 30 Aug 2012 15:51:38 -0400
- To: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
On Aug 30, 2012, at 1:27 PM, Ian Hickson <ian@hixie.ch> wrote: > On Thu, 21 Jun 2012, Trevor Burnham wrote: >> >> I've been using HTML drag-and-drop >> (http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html) >> in a project, but I've run into one limitation that seems severe to me: >> There is no direct way to determine what the source node is from a >> dragenter, dragover, or dragleave event. This makes it difficult to >> support use cases where elements react to those events differently >> depending on what is being dragged over them. > > This is intentional, because that source node could be from a Web page in > another origin, another browser, or indeed, an app that isn't even a > browser. So there's no real sane way to do it. > > >> I understand that the reason for this is cross-document drags: In >> addition to security implications, obtaining a reference to a DOM node >> in another document simply wouldn't make sense. Therefore, the >> dataTransfer object only allows serialized data. Unfortunately, >> dataTransfer is only appropriate for carrying data to the drop target. >> There is no mechanism for providing data to intermediate drag event >> receivers, except for the "types" attributes on the dataTransfer object. >> "types" can be used to carry data that you want to make public >> (http://stackoverflow.com/a/11089592/66226), but this is clearly a hack >> and it carries some limitations. Most notably, the spec requires that >> data type strings be converted to ASCII lowercase. >> >> Therefore, I'd like to propose the addition of a "publicData" object on >> all drag events. It would have the same interface and behavior as the >> dataTransfer object, with the sole exception that it would be read-only >> in all events where dataTransfer is protected. That is, publicData would >> be read/write in dragStart, and read-only in all other drag-and-drop >> events. > > That's an interesting idea. I suppose we could expose it using a custom > type in cross-app OS dnd situations, too. > > Could you elaborate on your use case? Are there cross-window use cases for > this? (For in-window cases, you could instead just use a global.) > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' The main use case I have in mind is an interface where elements respond to the object being dragged. A common case is showing visual feedback depending on whether the element emitting a dragenter/dragover is a valid drop target for the object being dragged. Currently, this can only be done in response to the types attribute. Using global state in tandem with the types attribute is a viable workaround for drags within a document, but an inelegant one. It's also incompatible with multi-touch. Although no multi-touch implementation of the dnd spec currently exists (to my knowledge), the spec does not preclude multiple simultaneous drags, so this may be a concern in the future. Trevor Burnham @trevorburnham
Received on Thursday, 30 August 2012 19:52:13 UTC