[whatwg] Limitations of the DnD API

On Sat, 20 Mar 2010, Stef Epardaud wrote:
> 
> I'm trying to implement the picture reordering feature of picasa in 
> HTML5 and I'm having several problems.
> 
> The feature is as follows:
> 
> - I have a list of small pictures arranged in a sequence of lines
> - I can select or unselect pictures by clicking them
> - I can drag the selected pictures to a new location, to reorder them
> - When I start dragging I have a drag image that shows what is being
>   dragged
> - It is possible to select non-continuous ranges of pictures
> - Pictures are arranged in sections represented by a picture-sized box
>   with the name of the section, followed by the section's pictures
>   themselves
> - It is possible to select a section, in which case all its pictures are
>   selected
> - When dragging, I want to update the drag image with information about
>   what happens should you drop things over here
> 
> I have tried several approaches for setting the drag image:
> 
> - Use Selection to instruct the browser of what is selected, and leave
>   the drag image alone, as this gives me the best drag image since
>   non-continuous images are represented with the selection "holes" in
>   the drag image.
> - Create a new DOM element to represent the selection and put some info
>   in there like how many images are selected and a few of the images
>   stacked together.
> - The same using a canvas.
> 
> Using the window.getSelection is nice visually but there's no way to
> update the drag image with contextual information. Also when adding the
> section boxes to the selection, their text becomes visually selected and
> that looks bad.
> 
> I did not find it possible to use a new DOM element to represent the
> selection, unless I append it to the document, which looks bad, since
> it's only meant for the selection.

The spec actually already supports this case -- when the drag starts, call 
dataTransfer.addElement() for each element that is being dragged.


On Sun, 28 Mar 2010, Stef Epardaud wrote:
> 
> "From this point until the end of the drag-and-drop operation, device 
> input events (e.g. mouse and keyboard events) must be suppressed."
> 
> This looks crazy to me. First Mozilla doesn't limit this since I was
> able to get a keypress event while dragging a node. I use this to change
> the behaviour of the drag operation with control/meta/alt keys while
> dragging, the same way file managers do it (at least Gnome Nautilus) and
> lots of other applications (Open Office for example). We need to be able
> to access key events while dragging. There might be a good rationale for
> this limitation stated in the spec, but based on evidence of how DnD is
> used in other applications perhaps it should be reviewed?

The state of the keyboard is in the drag events, so this shouldn't be 
necessary.


On Tue, 30 Mar 2010, Stef Epardaud wrote:
>
> But then it's up to the developer to detect that the keys weren't 
> pressed before (implement keydown events themselves), which is less 
> practical.

Why would you need to know the original state? Surely it doesn't matter 
how the user got to that state, you just need the current state.


On Tue, 30 Mar 2010, Stef Epardaud wrote:
> 
> But what was the rationale for preventing key events while doing DnD?

It's what IE does.


On Sun, 28 Mar 2010, Stef Epardaud wrote:
> 
> Personally I also use the key events while dragging to allow the user to 
> open folders in order to continue the drag operations inside, instead of 
> requiring them to drop the file in the folder, then open the folder and 
> drag it again to a subfolder.

Why would this use the keyboard? Surely the folder should just open while 
the user drags over it.


> I also have a question regarding DnD started in an external application:
> since we get no dragstarted or drag events, how can we detect that
> something wants to be dragged in the window? I want to highlight every
> responsive drop points so the user can know which elements are valid
> drop targets, but failed to get any meaningful interaction with
> dragentered or dragover on the document, or body elements. Surely that's
> a mistake from my part, but since I expect that it's going to be asked a
> lot (when we don't get drag or dragstart events), perhaps it should be
> mentioned in the spec?

You can detect it when you get a dragover anywhere in the document. 
However, since the user might be dragging over your window on the way to 
another window, you'll have to keep track of the dragleave events also, to 
make sure you don't keep the highlights up past the point of the last 
dragleave.


On Tue, 30 Mar 2010, Stef Epardaud wrote:
> 
> But if I want to be notified that an external application started a drag 
> in my document, where should I place the listener then? document? body 
> node?

The events bubble, so you can use either a capture or bubbling listener 
at the top of the document hierarchy (or whatever element represents the 
area over which the user has to hover before you show drag targets).


On Tue, 30 Mar 2010, Stef Epardaud wrote:
> 
> I couldn't get that to work properly with FF 3.6 and gave up after a few 
> crashes and hangs (which admitedly are not the spec's fault).
> 
> Why not make the implied drag and/or dragstart explicitely fired when 
> external applications start DnD in the browser? That might make it 
> simpler and more consistent.

It's better to have the browsers implement one thing than two things, 
since if they have to implement two things it'll take them twice as long 
to make them both bug-free.

However, even beyond this, having every Web page be notified whenever the 
user drags anything in any other app or Web page seems a bit weird, 
possibly even a sort of weak privacy violation.


On Mon, 29 Mar 2010, Daniel Cheng wrote:
> 
> In 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#effectAllowed-initialization, 
> is it intentional that any drag event can change the value of 
> effectAllowed for the next event? Does it make sense to making this 
> property settable only during dragstart / drag?

The spec basically is just describing what IE does. The API as a whole 
makes very little sense beyond this, sadly.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 8 April 2010 16:15:55 UTC