Re: Question about implementing DataTransfer.addElement
On Fri, 7 Oct 2011, Daniel Cheng wrote: What's the difference between addElement and setDragImage()? The spec says: The difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added (potentially keeping it updated as the drag continues, e.g. if the elements include an actively playing video), whereas the former uses the exact specified image at the time the method is invoked. For technical reasons, animating the drag image is non-trivial and not likely to be implemented in the near future, if it is ever implemented. However, if we don't implement dynamic drag image updates, doesn't that make it essentially the same as setDragImage()? In that case, what's the point of having addElement(); wouldn't it make more sense to just remove it rather than having two different ways of doing the same thing? The parenthetical isn't the important part (that's why it's parenthetical). The important difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added whereas the former uses the exact specified image. So for example if the user is dragging an element with some complicated CSS styles, that's what gets drawn with addElement(), whereas the author has no sane way of providing an image that contains equivalent pixels. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Question about implementing DataTransfer.addElement
On 10/10/2011 3:26 PM, Ian Hickson wrote: On Fri, 7 Oct 2011, Daniel Cheng wrote: What's the difference between addElement and setDragImage()? The spec says: The difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added (potentially keeping it updated as the drag continues, e.g. if the elements include an actively playing video), whereas the former uses the exact specified image at the time the method is invoked. For technical reasons, animating the drag image is non-trivial and not likely to be implemented in the near future, if it is ever implemented. What are the technical reasons? Is this something to do with OS level handling? Seems that on an OS level, an animated drag image might be something that the OS does not support. But for all intents, the OS does not need to support a drag image either. Should this kind of fallback be specified? I'd imagine that current OS X and Windows systems do support more dynamic dragging. If they don't, well, what about the next round? It does seem to me to be fundamentally different than images that are shown within the browser, where things can be animated by the UA. Once you're outside of the UA, it's really up to the OS capabilities. But, again, show me the proof: What are the technical reasons? There's no magic box here, the major OS APIs are open to all of us. -Charles
Re: Question about implementing DataTransfer.addElement
On Mon, Oct 10, 2011 at 15:26, Ian Hickson i...@hixie.ch wrote: The parenthetical isn't the important part (that's why it's parenthetical). The important difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added whereas the former uses the exact specified image. So for example if the user is dragging an element with some complicated CSS styles, that's what gets drawn with addElement(), whereas the author has no sane way of providing an image that contains equivalent pixels. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' It seems like setDragImage() does that as well: 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). Doesn't the otherwise clause describe exactly what addElement() does? Daniel
Re: Question about implementing DataTransfer.addElement
On Mon, 10 Oct 2011, Daniel Cheng wrote: On Mon, Oct 10, 2011 at 15:26, Ian Hickson i...@hixie.ch wrote: The parenthetical isn't the important part (that's why it's parenthetical). The important difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added whereas the former uses the exact specified image. So for example if the user is dragging an element with some complicated CSS styles, that's what gets drawn with addElement(), whereas the author has no sane way of providing an image that contains equivalent pixels. It seems like setDragImage() does that as well: 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). Doesn't the otherwise clause describe exactly what addElement() does? Ah, indeed. I forgot about that. I guess the difference then is just that addElement() lets you add multiple elements, but that's not a particularly great difference. If nobody implements it, or if people who implement it don't mind dropping it, we can drop it from the spec entirely. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Question about implementing DataTransfer.addElement
On 10/10/2011 4:15 PM, Ian Hickson wrote: On Mon, 10 Oct 2011, Daniel Cheng wrote: On Mon, Oct 10, 2011 at 15:26, Ian Hicksoni...@hixie.ch wrote: The parenthetical isn't the important part (that's why it's parenthetical). The important difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added whereas the former uses the exact specified image. So for example if the user is dragging an element with some complicated CSS styles, that's what gets drawn with addElement(), whereas the author has no sane way of providing an image that contains equivalent pixels. It seems like setDragImage() does that as well: 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). Doesn't the otherwise clause describe exactly what addElement() does? Ah, indeed. I forgot about that. I guess the difference then is just that addElement() lets you add multiple elements, but that's not a particularly great difference. If nobody implements it, or if people who implement it don't mind dropping it, we can drop it from the spec entirely. I'd like to keep it around for a little while, if that's possible. I could envision a UI where the clipboard or dragging interface does show multiple items. Many windowing interfaces now show medium-sized thumbnails of open windows as a user presses Alt+TAB. An interface to show multiple elements seems possible. I do understand that it's a rare case, may not be implemented, and may simply be a lot of work with little reward. -Charles
Question about implementing DataTransfer.addElement
What's the difference between addElement and setDragImage()? The spec says: The difference between setDragImage() and addElement() is that the latter automatically generates the image based on the current rendering of the elements added (potentially keeping it updated as the drag continues, e.g. if the elements include an actively playing video), whereas the former uses the exact specified image at the time the method is invoked. For technical reasons, animating the drag image is non-trivial and not likely to be implemented in the near future, if it is ever implemented. However, if we don't implement dynamic drag image updates, doesn't that make it essentially the same as setDragImage()? In that case, what's the point of having addElement(); wouldn't it make more sense to just remove it rather than having two different ways of doing the same thing? Daniel
Re: Question about implementing DataTransfer.addElement
On Fri, Oct 7, 2011 at 2:45 PM, Daniel Cheng dch...@chromium.org wrote: For technical reasons, animating the drag image is non-trivial and not likely to be implemented in the near future, if it is ever implemented. I would think that it's basically identical, technically, to implementing the element() function from CSS Image Values, which I believe we're planning to do. ~TJ
Re: Question about implementing DataTransfer.addElement
On Fri, Oct 7, 2011 at 2:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Oct 7, 2011 at 2:45 PM, Daniel Cheng dch...@chromium.org wrote: For technical reasons, animating the drag image is non-trivial and not likely to be implemented in the near future, if it is ever implemented. I would think that it's basically identical, technically, to implementing the element() function from CSS Image Values, which I believe we're planning to do. Not quite. With the element() function the 'live copy' still lives in the page and renders the same way everything else does. My understanding (and Daniel can correct me if I'm wrong) is that drag images do not render the same way due to platform integration concerns and so the technical cost for the two is fairly different. - James ~TJ
Re: Question about implementing DataTransfer.addElement
The way drag images work today is we take a snapshot and then hand it off to the system. To support addElement(), we'd need: 1. Some way to detect when that element has changed in visual appearance so we can update the drag image. 2. Some way to actually update the drag image in the middle of a drag. This is (as far as I'm aware) impossible with the documented interface for Windows DnD, and I'm not aware of an undocumented way to do it either. I'm more concerned about the latter, and while I don't believe it's impossible to solve, I think it would be difficult to make performant in case of things like video or other embedded content. Daniel On Fri, Oct 7, 2011 at 15:01, James Robinson jam...@google.com wrote: On Fri, Oct 7, 2011 at 2:56 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Fri, Oct 7, 2011 at 2:45 PM, Daniel Cheng dch...@chromium.org wrote: For technical reasons, animating the drag image is non-trivial and not likely to be implemented in the near future, if it is ever implemented. I would think that it's basically identical, technically, to implementing the element() function from CSS Image Values, which I believe we're planning to do. Not quite. With the element() function the 'live copy' still lives in the page and renders the same way everything else does. My understanding (and Daniel can correct me if I'm wrong) is that drag images do not render the same way due to platform integration concerns and so the technical cost for the two is fairly different. - James ~TJ
Re: Question about implementing DataTransfer.addElement
On Fri, Oct 7, 2011 at 3:18 PM, Daniel Cheng dch...@chromium.org wrote: The way drag images work today is we take a snapshot and then hand it off to the system. To support addElement(), we'd need: 1. Some way to detect when that element has changed in visual appearance so we can update the drag image. 2. Some way to actually update the drag image in the middle of a drag. This is (as far as I'm aware) impossible with the documented interface for Windows DnD, and I'm not aware of an undocumented way to do it either. I'm more concerned about the latter, and while I don't believe it's impossible to solve, I think it would be difficult to make performant in case of things like video or other embedded content. Ah, I wasn't aware that we simply handed the image off to the system and let it handle the drag. Ignore my message, then. ~TJ
