Reordering tables is notoriously hard because table formatting is mystical... ok, mystical is overstating it... perhaps it is better to say that cell, row, and table formatting is codependent, and so trying to pull something out and drag it around becomes... um... problematic.
I suspect the problem is more component than implementation. Your implementation is great because it gives us something to shoot for. I especially like what you've done with the arrow in the second example. - Eli On Sep 29, 2008, at 7:16 AM, Gonzalo Silverio wrote: > I'd be glad to and will do so - but I was not sure where the issue > was, on > the component or on the implementation - did not want to raise a false > issue. > > -Gonzalo > > > On 9/29/08 10:10 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED] > > > wrote: > >> Hi Gonzalo, >> >> Would you be able to file the bugs you found in jira? If not please >> let me know and I'll try to do it. >> >> I'm not sure if the reorderer has ever been used on tables before, at >> least I haven't seen it. >> >> Thanks >> Justin >> >> Quoting Gonzalo Silverio <[EMAIL PROTECTED]>: >> >>> Hi, >>> >>> We have been working on integrating the reorderer in the Sakai >>> announcements >>> list as a test. Here are some preliminary observations, some >>> caveats, and a >>> request for assistance. >>> >>> On the skinning side the selector order that worked best to avoid >>> conflicts >>> with external (implementor) styles and internal (reorderer) styles >>> was the >>> following: >>> >>> .orderable-default >>> .orderable-hover >>> .orderable-dragging >>> .orderable-selected >>> .orderable-avatar >>> >>> The only !important override was used in the ".orderable-avatar" >>> selector, >>> to override the ".orderable-hover" in cases where both were >>> addressing the >>> same attribute, since both are applied to the same element/state. >>> >>> Since ".ui-draggable" and ".ui-droppable" seem to be applied to >>> all states, >>> they were less useful for distinguishing between states. Is this >>> true? >>> >>> Oddities >>> -------- >>> The Sakai announcements list is a table, with up to seven columns, >>> each row >>> having a set of links and a checkbox input, at least when the site >>> owner is >>> viewing it. I applied the "uniqueprefix.orderableX" to the <tr/> >>> >>> - Win/Internet Explorer 6 - >>> >>> 1) Checkboxes are unchecked after a drag >>> 2) It is virtually impossible to "paint" ".orderable-drop-marker" >>> - the >>> table rows separate to the specified height as the avatar enters >>> the area, >>> but that is it, no background, borders, etc. are rendered. >>> >>> - All OS/Firefox 2/3 - >>> >>> A dropped row will sometimes drop as if the allowable droppable >>> target was >>> the first cell of the standard row. Adding anything to all rows that >>> explicitly gives it a block character (like "display:block, >>> display:table") >>> fixes this - but it makes a hash of the table layout. >>> >>> You can see the above at: >>> >>> Bare bones, shows Firefox problem: >>> >>> http://www.umich.edu/~gsilver/reorderer/index2.html >>> >>> Some attempt at styling, "display:table" applied to rows (I know, >>> I know): >>> >>> http://www.umich.edu/~gsilver/reorderer >>> >>> Any thoughts? Has the reorderer been used with a table before? I >>> think some >>> of the issues listed may be due to that perhaps? >>> >>> Many thanks. >>> >>> -Gonzalo >>> >>> _______________________________________________ >>> fluid-work mailing list >>> [email protected] >>> http://fluidproject.org/mailman/listinfo/fluid-work >>> >> >> >> > > _______________________________________________ > fluid-work mailing list > [email protected] > http://fluidproject.org/mailman/listinfo/fluid-work . . . . . . . . . . . . . . . . . . . Eli Cochran user interaction developer ETS, UC Berkeley _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
