Inconsistent behavior for resizable element with grid

[itai.leibowitz]

When creating a resizable element with grid setting, where the original size is inconsistent with the grid size, the behavior of the element changes based on which direction it is being resized. You get 4 completely different behaviors.

See the following jsfiddle with the inconsistent behavior: ​http://jsfiddle.net/kJbzU/

This was not an issue with the previous version (1.10.3), where regardless of original size, the allowed final sizes were all the same regardless of direction, and resizing in one direction never automatically changed the size on the other dimension

example with 1.10.3 below: ​http://jsfiddle.net/8HeVt/

[tj.vantoll]

Hi itai.leibowitz,

Thanks for taking the time to contribute to jQuery UI. This is because of a change to prevent resizables from moving (see #9611). Can you explain why you would have an element where the initial size is different than the grid size? That seems like a bad thing to do.

[itai.leibowitz]

There are different possible reasons, here are a few I could think of that made me use it:

1. You want an item that starts off at a specific size and can only increase by set steps - e.g. start at width 50 and only grow by multiples of 100. Google calendar is a good example: Minimal height of a meeting is 19px then grows by increments of 21 pixel per half hour. Minimal height is slightly lower than a full multiple in order to leave some space for a margin, but steps are constant because half an hour has a constant height on the grid.

2. You can use a large grid step to effectively prevent changing the size of the element in a certain dimension. For example I could set grid=[10000,10] to prevent resizing the element on the X-axis. Yes, you can also use max- and min- width, but if you don't know the initial width then this could be a simpler way to do so. With the issue discussed here, there is a problem with dragging north which will automatically increase the width of the element by 10000 and that is a problem.

I saw the previous issue that this was meant to solve and believe there could be a solution that solves both issues at once - they do not inherently contradict each other in terms of desired behavior.

Thanks for your help!

[tj.vantoll]

For the Google Calendar example though you would just define your grid to match the half hour increment, since you can always resize down to that height. Your second example I don't see anything you couldn't accomplish with a minHeight of minWidth. You can always detect the initial width before making the element resizable.

If you want to submit a pull request that covers this use case and #9611 with tests we can take a look. But I'm inclined to leave this behavior as is. If someone else on the team disagrees chime in and we can reopen.