Opened 11 years ago
Closed 8 years ago
#8219 closed bug (notabug)
Sortable: placeholder height/width incorrect if sortable item is resized
Reported by: | nicholasstephan | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 2.0.0 |
Component: | ui.sortable | Version: | 1.8.18 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
If sortable items have a css height then that height is used for the placeholder when dragging, even after that item has been resized:
http://jsfiddle.net/nicholasstephan/e9Dk3/
Remove the height attribute, or move it to an inline style, and it behaves as you'd expect:
Change History (5)
comment:1 Changed 10 years ago by
Milestone: | 1.9.0 → 2.0.0 |
---|
comment:2 Changed 10 years ago by
Status: | new → open |
---|
comment:3 Changed 10 years ago by
Summary: | sortable elements not updating height on element resize → Sortable: placeholder not updating height after element resize |
---|
comment:4 Changed 10 years ago by
Summary: | Sortable: placeholder not updating height after element resize → Sortable: placeholder height/width incorrect if sortable item is resized |
---|
This is not related to #4345 at all.
Updated and reduced test case against master: http://jsfiddle.net/tj_vantoll/UsdRn/. This is not just for the height but also the width. It appears the placeholder's dimensions need to be recalculated on mouse start.
comment:5 Changed 8 years ago by
Resolution: | → notabug |
---|---|
Status: | open → closed |
I'd actually say this is working as intended. Though the documentation on this isn't very good, the logic has always been that providing a custom placeholder class means that dimensions are not copied unless the placeholder ends up with no dimensions and forcePlaceholderSize
is set to true
. Since the placeholder has a defined height from the li
rule, that's what gets used.
While not ideal, you can add a class to all of the items and then put the height on that class: http://jsfiddle.net/UsdRn/8/
I think any change to this is likely to break existing uses, so I'm going to close as not a bug since the current behavior was actually intended. We'll likely reconsider pretty much every aspect of this during the rewrite.
Probably related to #4345, need to investigate a little more.