The helperContainer callback should provide the this context

[Tofandel]

If I want to append the sorted element within the element that is being sorted and not to the body (to not lose styling because there is a lot of css rules)
I need to pass helperContainer: function() { return this.container } as a prop, but the this is not passed as a context to the function so it doesn't work, replacing the function call by .call(this) effectively addresses the issue (another possibility is to just send the this attribute to the function, whichever is prefered)

I was also wondering why append the element to the body and not to the container by default? It would prevent a lot of issues like having to add a z-index to the element, having css rules you don't have power on that don't apply because the element is not nested within it's previous selectors, also prevents invalid html (If I have a <li> as a SortableItem, the <li> is directly appended to the body and that's not valid html, since it should be in an <ul>, having it in the original container also fixes this issue)

It would be a breaking change though since now people may rely on styling the element within the body although it should be minimal.

The .call(this) though is not a BC so feel free to make a release with only the first change and then a version bump with the second one

[pjshy]

I think the helperContainer callback provide the cloned sortable helper is useful sometime. But the context is complex.

[Tofandel]

@clauderic Any motion/thoughts on the PR please? It's been pending for quite some time

[Robin-Hoodie]

I was also wondering why append the element to the body and not to the container by default?

I was wondering the same thing. I imagine a lot of consumers of this library will need to work around this for the reasons you mentioned. Why not attach it to a more sensible default element or at least provide a simple option to attach it to the sortable container element?