Thanks again Paul My initial reaction is that it should be as simple and intuitive as possible - which it possibly isn't at the moment if you directly compare to the early version.
I'll do some more testing and thinking later in the week (out of play time for now!) and come back in jquery-ui-dev. Cheers Will On Dec 11, 2:43 pm, "Paul Bakaus" <[EMAIL PROTECTED]> wrote: > On Thu, Dec 11, 2008 at 3:34 PM, Will Kelly <[EMAIL PROTECTED]> wrote: > > > Ok I've updated the 1.6 example to have no margins to test this, > > however the first list item cannot be displaced by anything below, the > > rest including the last seem to work fine. (note the visual count can > > mess up but ignore this - legacy code). I've also checked the > > problem's not being caused by positioning the items relatively. > > That behaviour is due to the intersection method used, and technically > is correct, while not beautiful - this can be easily fixed by setting the > option 'tolerance' to 'pointer'. > > > > > Should it work with margins or is this a quirk with my html/css? > > Having to have extra boilerplate html is a bit annoying - however I > > understand you can reassign the draggable element via the 'handle' > > option. Any chance it can work more like the original version that > > works brillantly (apart from not scrolling!)? > > So, this is not a technical limitation but the margin is included by design. > I thought that if someone adds a margin to a draggable, that margin > should still be accounted for if a containment is set, so whenever you > drag to a boundary, the margin is still there. > > I'm actually not sure if that design choice should be revised - I see > cons and pros, so i might be good to start a discussion in jquery-ui-dev > for this. What do you think? > > > > > > > Thanks > > > Will > > > On Dec 11, 12:44 pm, "Paul Bakaus" <[EMAIL PROTECTED]> wrote: > > > The problem you're facing is that the margin of the list items is being > > > included > > > in the containment calculations, that means the bottom margin in your > > case > > > will > > > not be ignored during drag. But at the same time, the bottom margin seems > > > not > > > to make the actual list higher, so this causes the problem to occur. > > > > There are a couple ways to work around that: > > > > 1) Give the outer list a fixed height that's a bit higher (not a nice > > > solution, I know) > > > 2) Give the list a padding bottom > > > 3) Remove the margin from the li's and add it to a inner node > > > > On Thu, Dec 11, 2008 at 1:29 PM, Will Kelly <[EMAIL PROTECTED]> > > wrote: > > > > > Thanks Paul > > > > > That seemed to partially fix the problem, however the first item > > > > cannot be overlapped by the second and third, also notice dragging the > > > > third it doesn't go back to original position unless released. Is the > > > > containment including the margins of list items in its calculations? > > > > > Performance seems fine now. > > > > > thanks again > > > > > Will > > > > > On Dec 11, 11:20 am, "Paul Bakaus" <[EMAIL PROTECTED]> wrote: > > > > > Hi there, > > > > > > thanks for finding it, this is a bug. It was related to the order > > when > > > > the > > > > > containment was set, > > > > > and has been fixed by me today, as of revision 1095 in SVN ( > > >http://code.google.com/p/jquery-ui/source/browse/trunk/ui/ui.sortable.js) > > > > > > You said you had performance issues as well - I'd love to know if > > there's > > > > > any more issues > > > > > than this one. > > > > > > Thanks, > > > > > Paul > > > > > > On Wed, Dec 10, 2008 at 5:21 PM, Will Kelly <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > Hi > > > > > > > Have been upgrading a script that I wrote quite a few months back > > > > > > using 1.5beta to the latest version 1.6rc2 (using latest > > revisions). > > > > > > However it's not playing ball at all. > > > > > > > I've put up two versions both using the same calls to sortable, > > css, > > > > > > html files etc, > > > > > > > this.$list.sortable({ > > > > > > containment:'parent', > > > > > > start:this.funcPosStart, > > > > > > update:this.funcUpdateSortable, > > > > > > stop:this.funcPosStop > > > > > > }); > > > > > > >http://dev.logicbox.net/listsorter15b > > > > > >http://dev.logicbox.net/listsorter16rc2 > > > > > > > Setting tolerance to 'pointer' partially fixes the problem, but is > > > > > > dependent on where the pointer is placed on the item. > > > > > > > Have I missed some difference between the earlier and later > > versions?! > > > > > > Or is this a bug? > > > > > > > Thanks > > > > > > > Will > > > > > > -- > > > > > Paul Bakaus > > > > > UI Architect > > > > > --http://paulbakaus.comhttp://www.linkedin.com/in/paulbakaus > > > > -- > > > Paul Bakaus > > > UI Architect > > > --http://paulbakaus.comhttp://www.linkedin.com/in/paulbakaus > > -- > Paul Bakaus > UI Architect > --http://paulbakaus.comhttp://www.linkedin.com/in/paulbakaus --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
