Opened 8 years ago

Last modified 6 years ago

#7091 open feature

Droppable: Allow droppables to become visible and active during drag start

Reported by: eleotlecram Owned by:
Priority: minor Milestone: 2.0.0
Component: ui.droppable Version: 1.8.10
Keywords: Cc:
Blocked by: Blocking:


The summary says it all.

Use Case: Suppose you want droppables not to be displaying (display: none), until the right draggable (for which the droppable is accepting) is being dragged. The clean way to do this, is setting an activeClass on the droppables. In the CSS for this class you would set the display to 'block' (or something else than 'none'). This would then make the droppables appear.

Unfortunately, as it seems, jQuery UI Droppable won't set the activeClass to an element that is in fact in the DOM tree, except it is not displaying.

Live DEMO of the problem:


Change History (9)

comment:1 Changed 8 years ago by eleotlecram

Some investigations are leading me to believe the fix is trivial, it's merely a code order issue:

Currently, the visibility and geometry of the droppables are being evaluated *before* the droppable is activated. Simply activating the droppable *before* evaluating the visibility and geometry of the droppable fixes this bug. As far as I can tell from inspecting the code (and trying it out), it yields no nasty side effects.

From a purist point of view I'm also eager to believe its more logical to have a droppable become active before evaluating visibility and or position, because these, as I've pointed out in the bug report, may change as a side effect of becoming active.


comment:2 Changed 8 years ago by eleotlecram

comment:3 Changed 8 years ago by Scott González

Type: bugfeature

This is not a bug, it's as designed. What you want is a new hook prior to the checks.

comment:4 Changed 8 years ago by eleotlecram

When I first looked at the current behavior (of ui.droppable) (that is, without looking at the code), I was reasoning from the way I wanted to use ui.droppable. The initial post for this ticket was made given this background. And judging from the initial post text, I'm inclined to agree with you that it's a feature, not a bug.

However, after inspection of the relevant portions of the code, I'm no longer entirely sure that the current behavior may be the right behavior. Even though this current behavior might be `by design' –I have no doubt, judging from the code (which is very readable), that every portion of the code is well thought-out–, it is very possible that this design needs slight updating.

Call it a bug or not, I feel that the current design caches the wrong state (be it visibility, or geometry). Even though the ticket was started for the visibility aspect of the design, it may be more obvious to show that the design fails if we focus on the geometry aspect. To show this, let's give an example of perfectly legal use of jQuery and CSS for which the current design fails:

  1. If we assume that one of the ways CSS can be used, is to change the size (i.e. width or height) of a DOM element.
  2. If we assume that for a droppable one can specify the `activeClass', which, as documented, is added to the droppable's class attribute during drag 'n drop operations.

Then, combining propositions 1 and 2, it's possible to define an activeClass that changes the size of the droppables as soon as the droppable becomes active. (This size increase can be used to e.g. match the size of the droppable, or to have a better user experience, because it becomes easier to drop on a bigger droppable.) Unfortunately, the current design only considers the size of the droppable that it had *prior* to receiving the activeClass. And thus it calculates all intersections, snapping etc. with the wrong geometry.

To show this in effect, see:

So, while we can call this a new feature, or a new hook. Adding something new will not fix this current behavior.

If we can agree that the current design needs some rethinking and/or tweaking here and there, then we can move on to finding a solution. I'm still investigating to find one, but it isn't so obvious as it seemed at first glance.


comment:5 Changed 8 years ago by Scott González

Summary: UI Droppable won't set activeClass on elements in the DOM tree that are not displaying.Droppable: Allow droppables to become visible and active during drag start

What you just described is a bug, but it's quite different from what the ticket originally asked for. The bug can be fixed without changing the API and without breaking backward compatibility (and needs to be filed separately).

comment:6 Changed 8 years ago by eleotlecram

Would you agree if I state that the actual bug is that users cannot use all css properties in an activeClass.

Currently they are not allowed to use:

display, width, height, top, left, bottom, right, margin, padding,...

I don't feel like filing a bug that will allow activeClass to specify all properties, except for 'display'. I'd rather file a bug for which the fix implies that there are no more (known) unallowed properties.


PS I just thought of more potential problems ahead: The CSS3 Transition module.

Last edited 8 years ago by eleotlecram (previous) (diff)

comment:7 Changed 6 years ago by Scott González


comment:8 Changed 6 years ago by Jörn Zaefferer

Mike et al, could you check out the jsbins here and make this a (new) bug (or not)?

comment:9 Changed 6 years ago by Scott González

Status: newopen

There are two things at play here, from the description and the comments. The ticket summary/description is a feature request to be able to activate droppables that are hidden at the time of activation. The other is the ability to change the dimensions of a droppable via the activation. The latter should be handled by a refresh() method.

Note: See TracTickets for help on using tickets.