Resizable: fixed destroy so that it doesn't remove all sub (find) elem...

[christurnertv]

...ents with a class of ui-resizable-handle, but only children with that class from a target element. Fixed #8344 - Resizable: Destroy function removing ui-resizable-handle from inner containers

[scottgonzalez]

There are lots of other references to handles using .find(); this isn't an adequate fix. At a minimum, it needs to support custom handles, which can currently be at any level.

[christurnertv]

With the current implementation, it appears that custom handles can be anywhere within the resizable container, but not outside. Is this correct? Do you think it would be a bad thing to require that custom handles be a child of the resizable container?

[scottgonzalez]

Bad? No. Breaking change? Yes.

[christurnertv]

Fair enough. It does seems like any change that will allow nested resizable containers to work as expected (in regard to this issue) will break the current "you can have custom resize handles at any level below the parent resizable container". Even if you introduced custom names and classes for the handles that again would be a new requirement and breaking change. I'm new to this, how do you all handle such things?

[scottgonzalez]

We wait until a major release to introduce the change. However, since resizable is being rewritten, we're not allowing any API changes.

[christurnertv]

Ok, thanks for your time and the info Scott.

[dekajp]

@scottgonzalez - since resizable is being rewritten finish ?

[scottgonzalez]

@dekajp I don't understand the question.

[dekajp]

@scottgonzalez are we done with rewritting or is it in progress ?

[scottgonzalez]

The interaction rewrite is in progress. See the interactions branch(es).