Up !
On May 30, 6:23 pm, Lideln <[email protected]> wrote: > Up ! > > On May 27, 2:08 pm, Lideln <[email protected]> wrote: > > > up ! > > > On May 24, 3:27 pm, Lideln <[email protected]> wrote: > > > > Hi all, > > > > As a jQuery lover, I was sooo sad to fall upon a few bugs in the > > > resizable plugin. > > > Here they are : > > > > 1) CSS : > > > Issue : I had to add the ".ui-resizable" css for that plugin to work > > > (hopefully I found a website explaining that workaround). > > > Proposal : automatically add the style if not found (is that > > > possible ?), or at least explain it on the resizable doc page. > > > > 2) Scroll option : > > > Issue : there is no "scroll" option as in draggable. Although it seems > > > to be "false" by default in the resizable plugin, which is great for > > > me, but maybe not for everyone. > > > Proposal : implement the same behavior for "containment" and "scroll" > > > options of the draggable plugin. > > > > 3) Containment option : > > > Issue : the containment option does not work vertically on the > > > official example (http://jqueryui.com/demos/resizable/#constrain-area > > > you are constrained horizontally, but not vertically). In my > > > application, this is worse, the resizing stops before it gets to the > > > right (and bottom) edges of the container (I do not see the official > > > example vertical bug). My best guess (I'm almost sure) is that maybe, > > > to detect the end of the edges, you take the absolute position of the > > > resized element instead of the relative one (see the "position > > > absolute" bug below). In that case, the top and left > > > "position" (computed) of the container are not taken into account. > > > Which leads tosomeissues: the resizing stops before getting to the > > > right and bottom edges of the container, and the resizing allows to > > > move to the (0, 0) position in the body. > > > Proposal : use the relative position of the resized element (within > > > the container) to determine the resize boundaries, or add/substract > > > the (computed) position of the container to alter the boundaries (but > > > the first option is preferred, see the "position absolute" bug below) > > > > 4) AlsoResize option : > > > Issue : when the alsoResize option is used with the containment > > > option, the containment option is not taken into account for the > > > "alsoResized" element (see my test code below). > > > Proposal : the alsoResize option is really great, but I think it'll > > > needsomecleaning (there may be other bugs, like for example when the > > > "alsoResized" element has a vertical scrollbar, and you resize the > > > "real" element toward the left: 0 position, the scrollbar moves to the > > > right of the alsoResized element) > > > Another idea : this idea is not related to a bug, but maybe it could > > > be great if you could implement the "resize-type" of the "alsoResized" > > > option (I mean : only horizontally, or only vertically, or both, and > > > so on) > > > > 5) Handles : > > > Issue : when you apply the resizable plugin to an element, the handles > > > are "hidden". Not "hidden", but I mean they are not "block". Let me > > > explain : I have a functionnality in my application that allows, as > > > under linux, to reduce a window to its simple title bar when dblclick > > > on it (in fact I just hide the window content, see example below). I > > > apply the resizable plugin, and dblclick : everything is fine. But if > > > by chance I resize my window even just by 1px, and then dblclick on > > > the title, the contents hide but the handles "take place" as "block" > > > elements, and the window stays "open". > > > Proposal : mmmh I don't know. Maybe I could hide the handles by myself > > > and show them afterwards. But it is not clean. Is there a way that you > > > "modify" them (after resizing) so they return as the initial "non- > > > block" state, when you first apply the plugin ? Because it does not > > > bug in that very case. > > > > 6) Position absolute bug : > > > Issue : when I resize the element, I think that its position is > > > transformed into an absolute position, independant of the initial > > > container. In fact, I log the top and left css positions of the > > > resized element in the console when I drag it. When I drag it to the > > > top-left corner of my container (after I have applied the resizable > > > plugin BUT before having it resized), the position is (0, 0), which is > > > normal. But when I resize it by even 1px, then the position becomes > > > (23, 96) (which corresponds to the left and top position of my > > > container). > > > Proposal : don't force/use absolute position, please. > > > > 7) Disable/Enable option : > > > Issue : when I found this option, I was really pleased, because in the > > > case my window is "titled" (reduced to its simple title, contents > > > hidden, as under linux), I do not wish to allow resizing of course. > > > Then I used this option to disable/enable resizing. The problem is, > > > that when disabled, somehow there are resizable plugin functions that > > > are called, because : > > > * I get the "position absolute" bug (see above) > > > * I receive the stop() callback... > > > (and I don't know how since everything is hidden) > > > Proposal : do not launch ANY resizable-plugin function when in > > > disabled state (callbacks, positionning, and so on) > > > > That's all, now I will post another message to give a complete test > > > case for those who need it. > > > > Thank you all, have a nice day ! > > > > Renaud --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery UI" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-ui?hl=en -~----------~----~----~----~------~----~------~--~---
