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 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.
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
