I can't remember who said "there are no dumb questions".
I don't do that because, as I said, it also bugs in the official
example.
And even if I did and if it worked, it would only correct one of the 7
points discussed earlier.
There is a more deeper thought to have regarding this plugin, because
as I mentionned, it lacks several things, and there are several bugs.
I think that developers of this plugin should at least answer me that
they will investigate this... But no answer for around 1 month !

I'm a bit disappointed, I must admit. I did not expect a bug fix in
the next hours following my first message, but at least an answer.


On 22 juin, 00:08, Charlie <[email protected]> wrote:
> dumb question.......if it's not working why wouldn't you use same markup and 
> classes as examples then get the modules working then tinker with markup?
> Lideln wrote:Up ! On Jun 18, 8:23 am, Lideln<[email protected]>wrote:Up ! On 
> Jun 13, 2:23 pm, Lideln<[email protected]>wrote: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-areayou 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....
>
> plus de détails »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to