Bug Fix / Enhancement for alsoResize method

There is a logic bug in the resizable.alsoResize.resize._autoResize subroutine that adds top & left css values to child-elements of the main resizable element. This is illogical and creates a nasty positioning bug when anything other than position: static is used.

The bug is actually always there - in the form of illogical CSS - but only becomes visible when the autoResize element has position relative or absolute. It is easily seen in the dialog widget, which sets the ui-dialog-content element as an alsoResize element. To trigger the bug, simply add position: relative to the ui-dialog-content element. It's not unusual set position-relative on a DIV used as a dialog elements, so this is not an edge-case.

Here is an example of the bug in a basic dialog box...

http://layout.jquery-dev.net/samples/ui_dialog_bug.html

The _autoResize method also has a redundant properties array - declared both as the 'default variable' and again as a default when used in the $.each statement. Since it is this array that required patching, I also eliminated that redundancy.

Here is the revised subroutine...

_alsoResize = function(exp, c) {
    $(exp).each(function() {
        var el = $(this), start = $(this).data("resizable-alsoresize"), style = {}, 
            css = c && c.length ? c : el.parents(ui.originalElement[0]) ? ['width', 'height'] : ['width', 'height', 'top', 'left'];

        $.each(css, function(i, prop) {
            var sum = (start[prop]||0) + (delta[prop]||0);
            if (sum && sum >= 0)
                style[prop] = sum || null;
        });

        //Opera fixing relative position
        if (/relative/.test(el.css('position')) && $.browser.opera) {
            self._revertToRelativePosition = true;
            el.css({ position: 'absolute', top: 'auto', left: 'auto' });
        }

        el.css(style);
    });
};

The only change is the css variable. Previously it ''always'' included both position (top/left) and size (width/height) properties. Now if the resizable element is a 'parent' of the alsoResize element, it skips the position properties because the inner element's position is relative to it parent(s), which ncludes the element being resized. Therefore it is illogical and incorrect to change the inner-element's position.

I hope this will accelerate getting the bug patched. Currently I must work around it by adding an inner-div within the content-div so that I can have relative positioning. I'd like to avoid this extra, non-semantic markup.

Cheers,

Kevin Dalman