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

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.

__

Marcel

Sent a pull request (https://github.com/jquery/jquery-ui/pull/148)

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

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: http://jsbin.com/ahaze4

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.

__

Marcel

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

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.

__

Marcel

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

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

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.