-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Repaired draggable; specifying an element as its own handle works once again. #963
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.
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
Conversation
This won't be restored. Handles should be descendants, not the element itself. |
Hi Scott - can you explain why this functionality won't be restored? This is a breaking API change which in turn breaks an API we advertised to our own users. |
Whether or not it used to work, it was never documented to behave that way. We don't consider changing undocumented behavior to be a breaking API change because whatever isn't documented isn't part of the API. |
Hi Scott - it seems that at least one other user (Steve, who submitted the API fix after you changed the behaviour) considered the previous behaviour was documented clearly enough. The API used to read "If specified, restricts dragging from starting unless the mousedown occurs on the specified element(s)" which described the old behaviour reasonably clearly, and does not describe the new behaviour. "on the specified elements" I think most people would read as clearly including the elements themselves. However, sorry that my initial question wasn't expressed better - I was asking more about the rationale behind the change - that is, how is the change helpful to users? I regard the new behaviour as less helpful - since it is possible to assemble a set of "closed" DOM sets to equal any set of "open" DOM sets but not vice versa (call a DOM set "open" if it consists of all descendants of a node minus the node, "closed" if it includes the node). Unless I'm misunderstanding how the new API can be used, there are some situations that now cannot be represented - for example, a "portal"-like UI where a portal features a title bar which is a single DOM node, which does not have a unique ancestor, but the portal must be draggable by only the title bar. Have I missed a way in which the new API can cater for this situation without telling the user to change their markup? |
I have no idea what you're describing with the portal. How is the portal itself not the unique ancestor? Every "portal" I've ever seen has this basic structure: <div class="portal">
<div class="portal-header"></div>
<div class="portal-content"></div>
</div> And the following, very simple logic works: $( ".portal" ).draggable({
handle: ".portal-header"
}); |
If there are no further nodes within portal-header, I believe it would not work. |
Reduced test case or it works. |
Thanks for the clarification, Scott - I had misread the restriction as applying to descendants of the handle rather than descendants of the draggable node. |
As of cdff72e, this stopped working:
This pull request consists of a test and a fix that restores that functionality.