The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Here's a screenshot of the issue:
https://skitch.com/jesse.beach/g65a9/panels-d7.drupal.dev
I've seen this in numerous modules, but this particular screenshot was taken from the layout list of the Panels module.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 4f2fc645d535cf253b000006.jpeg | 21.05 KB | nicholasthompson |
| #4 | ctools-dropbuttons-outside-table-cell-1429240.patch | 1.23 KB | nicholasthompson |
| #3 | 4f2fc030d535cf6e6300000b.jpeg | 24.95 KB | nicholasthompson |
| #1 | dropbutton_positioning-1429240-2.patch | 971 bytes | jessebeach |
Comments
Comment #1
jessebeach commentedThis is a one-line patch to add position:relative to the td that contains the dropbutton.
Comment #2
merlinofchaos commentedThis is already reported in http://drupal.org/node/1336102 but I'm marking that one a dup since this has a patch.
Note: This problem seems to be specific to the overlay for some reason. Are you sure relative is the right answer? Does this continue to work properly when not in the overlay?
Comment #3
nicholasthompsonI have this problem with Overlay disabled. Initially I thought it was a problem with the Admin module at first (some kind of margin-left issue)... However it also happens when disabled. See attached.
I've tried applying that patch, it has made no difference...
Comment #4
nicholasthompsonRevised patch - there are two places this is needed. I've done a "grep" to look for other mentions of "operations" in CSS files. Seems to be the only two I could find.
Comment #5
nicholasthompsonOn a side note, the result is that sometimes dropbuttons no longer fit in the cell.
Comment #6
jessebeach commented@nicholasThompson, interesting, let me see if I can make the buttons more flexible so they don't burst their cells.
Comment #7
nicholasthompsonThe issue, obviously, is that they're
position:absolute.I had a VERY quick go at changing it. Removing the absolute position made them "fit" nicer, however when they expanded the container made the cell larger too.
I guess the safest way is to make the button and "child menu" sibling elements (rather than parent/child). That way the button can have dimensions/size/presence in the cell (to make it "fit") and the child menu can be absolutely positioned to avoid the expansion effecting the cell.
Just an idea :)
Comment #8
jessebeach commentedre:#7, that's a great idea. I'm experimenting with an approach. If you have one nicholasThompson, you should post it and we can work on it together.
Comment #9
nicholasthompsonI dont have any code unfortunately, sorry.
The only downside to my idea is accessibility. At least with the parent:child model you can use CSS and
:hoverpsuedo classes to let people use it if they have no JS.I *guess* we could add a CSS rule for (IIRC)
body.no-jsto make sure the sibling menu contents are visible if JS is disabled?Then AGAIN... If you have no JS, you'd have done pretty well to get to that page and to use Views/Panels/CTools in the first place ;)
Comment #10
merlinofchaos commentedViews actually should be usable without .js
Panels less so, but the places where CTools is using dropbuttons should be completely accessible without .js
Comment #11
merlinofchaos commentedI committed another patch that theoretically addresses this, but does not completely.
Comment #12
tim.plunkettPlease update with more info after trying the latest version.
Comment #13
esmerel commentedIt's been a month - I'm going to go ahead and close this, but it can be reopened if it's still broken.