Skip to content

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

Closed
wants to merge 1 commit into from
Closed

Repaired draggable; specifying an element as its own handle works once again. #963

wants to merge 1 commit into from

Conversation

steveluscher
Copy link

As of cdff72e, this stopped working:

var element = $('#draggable');
element.draggable({ handle: element });

This pull request consists of a test and a fix that restores that functionality.

@scottgonzalez
Copy link
Member

This won't be restored. Handles should be descendants, not the element itself.

@amb26
Copy link

amb26 commented Dec 23, 2013

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.

@scottgonzalez
Copy link
Member

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.

@amb26
Copy link

amb26 commented Dec 23, 2013

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?

@scottgonzalez
Copy link
Member

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"
});

@amb26
Copy link

amb26 commented Dec 23, 2013

If there are no further nodes within portal-header, I believe it would not work.

@scottgonzalez
Copy link
Member

Reduced test case or it works.

@amb26
Copy link

amb26 commented Dec 23, 2013

Thanks for the clarification, Scott - I had misread the restriction as applying to descendants of the handle rather than descendants of the draggable node.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants