Skip to content

Avoid setting display: block on dropped cell #130

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
apelliciari opened this issue Sep 30, 2014 · 2 comments
Closed

Avoid setting display: block on dropped cell #130

apelliciari opened this issue Sep 30, 2014 · 2 comments
Labels
bug

Comments

@apelliciari
Copy link

Hi, i have a table with td elements, which have display: table-cell.

When i drop something on them, the dragndrop module sets them to display: block and they lose the alignment (the table is a calendar).

is it possible to avoid setting it?
codef0rmer pushed a commit that referenced this issue Oct 1, 2014
@codef0rmerz
chore(*): version bump 1.0.8
c2d68f1 
  - Closes #125, #121, #99 - Fix paradox of choice ($ vs jQuery)
  - Closes #122 - Update jQueryUI depedency in demos and tests
  - Closes #130 - Restore display value if set, else use block
  - Closes #128, #36, #30 - Restore zIndex value always
  - Closes #117, #110 - Fix destroying widgets prior to initialization
  - Closes #111 - Allow dropping without ngModel similar to dragging
@JesseDahl
Copy link

I think I'm still having the same issue with the latest version 1.0.8. I had a droppable div element with the css property display: 'inline block' set, and on drop it was changing it to 'block'. I think the culprit is lines 150/151 in angular-dragdrop.js.

 toPos = $toEl.css({'visibility': 'hidden', 'display': 'block'})[dropSettings.containment || 'offset']();
 $toEl.css({'visibility': '','display': wasVisible ? 'block' : 'none'});

If I understand this part of the code correctly (I've just really skimmed it so I could easily be wrong), on drop it's replacing the display property with 'block'.

If I'm wrong, it's something else in my code. But just wanted to throw this out there in case it's still an issue for anyone else.

@codef0rmer
Copy link
Owner

@JesseDahl: Oops, I missed that one. I'll fix it soon.

@codef0rmer codef0rmer added the bug label Nov 22, 2014
@codef0rmer codef0rmer reopened this Nov 22, 2014
codef0rmer pushed a commit that referenced this issue Jan 4, 2015
@codef0rmerz
chore(*): version bump 1.0.9
87fffa1 
  - fix(README): Closes #108 and [cleanup](7c06a61)
  - fix(*): Closes #102 - use $.map over native .map method for IE8
  - fix(*): Closes #137 - drag/drop should work even when compile-time debugging is disabled
  - fix(*): Closes #130 - avoid setting display: block on dropped cell
  - fix(*): Closes #102 - passing global jQuery reference in case it is renamed with jQuery.noConflict()
  - fix(*): Closes #143 - introduce deepCopy option to support deep copy on draggable/droppable
  - perf(*): Undo #55 because some callbacks are performance intensive, especially, onDrag, to run a digest loop for. Call $scope.$apply() within the callback if needed
  - fix(*): Closes #144 - default or custom confirmation before drop
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@codef0rmer @apelliciari @JesseDahl