Re: [whatwg] Proposal for public data in drag events
On Aug 30, 2012, at 1:27 PM, Ian Hickson i...@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
Re: [whatwg] Proposed addition to Drag and Drop API (Alex Bain)
I did a bit of reading about what the WhatWG spec says setDragImage should do and wanted to ensure I understand what the spec is saying and how Webkit is behaving. Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dom-datatransfer-setdragimage The spec says defines setDragImage as: setDragImage(element, x, y) Element argument is defined as: If the element argument is an img element, then set the drag data store bitmap to the element's image (at its intrinsic size); otherwise, set the drag data store bitmap to an image generated from the given element (the exact mechanism for doing so is not currently specified). This says, if I'm understanding it correctly, that I can provide any element as the first argument and a bitmap image will be generated as a drag image. This would allow me to accomplish what I'm trying to do (setting a small drag element to represent a larger draggable container). However, in my testing, Webkit will not render anything unless the element specified is an image. Am I misunderstanding the spec, or might this be a bug in the implementation? I can't say which without an example of how you're using setDragImage, but I assure you that it works with non-img elements in WebKit browsers: http://jsfiddle.net/mZGP7/1/ Note, however, that (at least for WebKit-based browsers) the element must be in the document body, and it can't have visibility: hidden or display: none or even positioning that puts it outside of the window bounds. None of this is dictated by the spec, which simply declares that the mechanism for turning an element into a bitmap is unspecified. At this point, I would take your questions to StackOverflow rather than the WHATWG list (unless you would like to draft a proposal for making the setDragImage spec more precise). Best, Trevor
[whatwg] Proposal for public data in drag events
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. 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. Thoughts? Cheers, Trevor Burnham
