I was thinking exactly this as I read the problem. Never seen it in the wild but it would solve the ux

A possible solution is collapsing rows into "ghost" representative rows while dragging so you can see more at once, and using a more minimal drop indicator instead of a full-height item.

I was thinking exactly this as I read the problem. Never seen it in the wild but it would solve the ux

A possible solution is collapsing rows into "ghost" representative rows while dragging so you can see more at once, and using a more minimal drop indicator instead of a full-height item.

There is something like it shown here:
https://uxdesign.cc/drag-and-drop-for-design-systems-8d40502eb26d

I also think I have seen it in the wild but can't recall where.

looks like its quite simple to do using the dragula library we have.

Yes, but subforms appear not to be using dragula from what I can tell. (I'm not sure why.)

?

@wilsonge @dgrammatiko do you all know why this is using it's own thing instead of dragula? It looks like it was like this in j3 but not sure when dragula was introduced.

Would there be any problems in refactoring this to use dragula?

Actually, after poking around Dragula I can see that it's not accessible and has no keyboard support. :( bevacqua/dragula#538

Every issue I open gets more complicated than I intend ?

@crystalenka check #19184 (comment) and maybe follow the whole conversation in that PR. The JS-group was aware of all the issues back in 2017 but I guess 2-3 people were not enough to do the mammoth task of dropping jQuery and making everything accessible. BTW Dracula seems to be abandoned (same goes for the shopify draggable)

@crystalenka check #19184 (comment) and maybe follow the whole conversation in that PR. The JS-group was aware of all the issues back in 2017 but I guess 2-3 people were not enough to do the mammoth task of dropping jQuery and making everything accessible. BTW Dracula seems to be abandoned (same goes for the shopify draggable)

I understand. Me opening issues to address things doesn't discount the hard work done before. Just trying to make it better. :)

This seems to be the most complete answer to accessible drag and drop, and it's based on dragula: https://github.com/schne324/dragon-drop

However both this and dragula seem like they are no longer maintained.

This is also an excellent resource and the up/down arrows available make it easier too for people with limited mobility in their hands: https://www.darins.page/articles/designing-a-reorderable-list-component

However both this and dragula seem like they are no longer maintained.

Not updated doesn't necessarily = not maintained

Not updated doesn't necessarily = not maintained

Brian, I know the difference and I'll say again that the project is not maintained. You can see the efforts to bring it back to life from Lea Verou: bevacqua/dragula#689 (comment) (btw I had a PR on her repo but effectively we end up forking it for our own use cases).

This seems to be the most complete answer to accessible drag and drop, and it's based on dragula

Yes, I maintain a private fork of that repo on top of the dragula...

Either way, the last link I sent has a nice example of reordered lists with the minimal drop indicators etc that I mentioned; the up and down arrows would help a lot also in mitigating this issue.

the up and down arrows would help a lot also in mitigating this issue.

Joomla had those a decade ago and people didn't really liked the UX... Also mentioned in the original PR of subforms (quoting Brian here): #19184 (comment)

Given that the use and implementation of subforms has evolved far from the original, I'm not sure it's fair to quote comments from 5 years ago. We've all learned quite a bit in that time, and the context of use is now different.

Fair enough, I don't have strong opinions about the up/down buttons in this context (I think for the list views would be counterintuitive but for subforms (edit view) might be ok)

About the issue here I have couple comments:

• The subforms don't have a title/description so it would be interesting to find a way to collapse the inputs in such a way that a user would not loose track of the selected (dragging) element. Making the shadow (the dragged element) a generic placeholder might be counter intuitive (especially for existing users).
• The current implementation should be accessible at least that was our perception at the time when @Fedik did the PR
• There are known security vulnerabilities (yes I know people are more attracted to the UI/UX than any underlying, harder to tackle issues), just saying it's not only the look and feel

Just from a usage approach, I had to implement up/down arrows (which were then used most of the time) especially for large forms (when scrolling is needed) and for mobile usage.

You make field accept-drops by adding acceptDroppables() port.

Same way you can miscil which types of drops is acceptable; example: accept JPG, DOCX, etc.

By default, however, due to security restrictions, most our servers disallows drops.

Im reminding you that instralling J! in AJP is considered mitworthy.

@wojtekxtx once again you post nonsensical text that is absolutely nothing to do with the issue here

@brianteeman I honestly dont see how my post is nonsensical. Dare to explain?

You talk about fields and filetypes.

Related #37974

@Quy how is that related. Its a completely different issue

A possible solution is collapsing rows into "ghost" representative rows while dragging so you can see more at once, and using a more minimal drop indicator instead of a full-height item.

That would be ideal but when using native draggable the "ghost" is actually an image representation of the item being dragged. Other than the background nothing else appears to be "stylable".

Everything is controlled by the browser. At 300px it changes behaviour - see https://codepen.io/thetallweeks/pen/WNYeod

(ps: What am I missing in that all my fields are displayed horizontally when yours are vertically)

(ps: What am I missing in that all my fields are displayed horizontally when yours are vertically)

It switches layouts when you have 5 or more fields in a subform.

That would be ideal but when using native draggable the "ghost" is actually an image representation of the item being dragged. Other than the background nothing else appears to be "stylable".

That is a true bummer. I'm sure there's a solution though... hm.

Everything is controlled by the browser. At 300px it changes behaviour - see https://codepen.io/thetallweeks/pen/WNYeod

It varies by browser too—in Safari, the behavior is exactly the same on both elements.

That is a true bummer. I'm sure there's a solution though... hm.

the only thing I found was this old post from an old old friend https://www.kryogenix.org/code/browser/custom-drag-image.html

as i understand
if we have many field in subform we have a problem
we can use table display => not reponsive and display is exploed on right. Bad solution
maybe we can use 'span' option deuce height of subform zone, but doesn't works...
yes maybe just reduce height of zone on dragstart event like @crystalenka ?

Adding a +1 to this one. Dragging Subforms really took a step back in usability in J4 compared to J3 :(

Please test #42334

Please test #42334

This approach is a bit reductive and I don't feel like it fully addresses the issue. Dragging and dropping is still very bad, and I don't think adding an up and down arrow is enough to call the problem solved...

Dragging and dropping is still very bad

Dragging a large piece of Content is not very practical.
Realistically I do not think it can be fixed in another way, without over-complication.

But if people do not agree, we can reopen this issue.