Rewrite tabledrag.js to use jQuery UI

That should be a "refactor tabledrag" issue, It's not very efficient and quite messy.

Best case is making it work with jquery ui sortable, there are a few gotchas to it but it should work.

Makes much more sense to rewrite than refactor after all. That's the slowest piece of JS code in drupal core and it's not a great design.

If someone wants to tackle that, remember that we only need IE8 compatibility, it might not be necessary to rely on jQuery/UI for that. It needs to be mobile friendly somehow.

Rumour has it the jquery ui team is working on bringing touch event support to drag and drop. We could gamble on that getting in before D8 and head that direction.

I'm actually on the fence about adding plugins. Some look like they may be helpful, but I'm not seeing anything terribly compelling either. I still wanted to add evaluating them to cover those bases.

Don't like plugins too much either but whatever works :)

#817176: UI Pattern suggestion for better accessibility of table drag implementation

When working on tabledrag.js, keep in mind that a lot of work went into making an accessible mode. The "show row weights" functionality is not the most beautiful UX compromise, but it does allow D7 to be accessible so that all people are able to re-order menus and build a Drupal site.

If we're going to re-think tabledrag, accessibility needs to be a consideration.

It might be good to clarify whether this issue includes a UI change or not. If we are just refactoring the code but leaving the UI untouched, then you don't need to do so much coordination and build consensus with the UX and Accessibility teams.

Well I'm just planning on a js refactor, not touching the UI. If people want to change the UI it's in the other thread.

If the refactor is well done it should be easy to change/tweak the ui without having to change everything :)

@nod_ that greatly simplifies things. The accessibility team is always eager to help if this grows into a UI change, but this will be simpler. We'll be glad to test when a new draft of this is ready. Thanks!

Updated issue summary for clarification and to cross reference #1261002.

Added accessibility concerns to issue summary.

Been looking into this as well for a D6 site.

I would recommend writing your own custom JS rather than using a plugin to reduce cruft not needed in core. With that said, I would also write the new tabledrag as a plugin, so that others can use it in the frontend on their sites easily.

I have another "speed fix" for tabledrag here:
#1571814: tableDrag.js, reduce the number of calls of .length from 33478 to 455

I've also been looking into an optimal setting for this.scrollSettings.interval which is used as the miliseconds to setInterval with regards to scrolling the window. Currently it's set to 50ms, which seems like it could be a little higher to reduce browser load and not be noticeable to the end user. 100ms, could reduce the amount of calls in half and still provide 10 updates a second. From checking the issue queue it doesn't appear there's been any discussion to this variable.

closing #1415828: Tabledrag should be a library for this one. and bring last patch from the other issue here.

Hrm. This issue here looks like a major effort, which might even take months to complete, given how much research and also testing will have to be done. Contrary to that, #1415828: Tabledrag should be a library is a very trivial refactoring (and the replacement of jquery cookie was never within the scope of that issue).

I'd really prefer to be on the safe side for D8 and do the trivial refactoring first, which can land at any time and does not require manual testing. Therefore, I'm going to re-open the issue.

@bowersox, @all: the scope of this issue just changed, there will be UI changes.

Bojhan and I will be doing some brainstorming this friday around this, so if you have ideas/mockups about how you'd like to see tabledrag working please post your ideas in #817176: UI Pattern suggestion for better accessibility of table drag implementation :)

There is a working patch over at #1268530: drupal_add_tabledrag: Add javascript hooks for module writers that adds a custom event when a row changed. The new implementation should provide custom events for various actions as well.

I like this issue a lot. Taking the jQuery UI route would benefit from #1085590: Update to jQuery UI 1.9.

There are a few other efforts to revamp the table drag in D8.

Mostly wanting to tag this to verify that it still works with screen readers & keyboard only users.

There are several issues with the jquery road.

1) Table row dragging is not officially supported. I made a prototype and it worked though (IE? don't know)
2) There is no tree-like structure supported
3) I am not sure we can support the move restrictions we currently have.

Now there are serval new things since my testing:
1) we're moving to admin lists (ul, li and all that) for admin tables #1276908: Administrative tables are too wide for smaller screens, so that'll help with jquery support
2) with that we can nest lists and have a proper tree structure with nested lis (ok, that one is a loooong shot but it might be possible), which would help for setting up jquery sortable and make it possible to implement the same kind of restrictions we have right now.
3) I'm happy to get rid of some of them, the mobile thing will likely kill a couple of them as long as nobody wants the exact same UX we should be good.

This stuff needs to work well on mobile, bumping to major since it currently doesn't and that's a lot of work needing to happen before december.

#194283: Add an undo button for drag/drop operations
#1164804: Table rows are intended to allow dragging, but this is not clear.
#920076: With the drag/drop when switching between 'drag mode' & 'manual mode' the order should follow

BONUS: Investigate if adding basic events and detach makes sense, as described in #1763812: [META] Provide complete attach/detach with basic events.

It probably makes sense to add this.

tag

Re #18, we ended up not using lists for responsive tables - they are good ole table tags. So this stays relevant and important. Keep on going, guys!

Trading major to get attention on #1261002: Draggable tables do not work on touch screen devices.

1) Table row dragging is not officially supported. I made a prototype and it worked though (IE? don't know)
2) There is no tree-like structure supported
3) I am not sure we can support the move restrictions we currently have.

Hi guys, looks like @nod_ already identified all the issues. But as the original author of tabledrag.js, I wanted to reiterate that there was a *reason* why we didn't use jQuery UI to begin with. If jQuery UI would have been a good fit, we probably would have used it, even back then in Drupal 6. However jQuery UI wasn't and still isn't a good fit for table drag. Moving table rows outside of their parent table does not work at all. The DOM simply does not allow it. I tried this approach when tabledrag.js was originally written and it won't work.

There is definitely places for improvement in tabledrag, especially around performance. However right now the biggest slowdowns with tabledrag isn't the JS itself, it's the number of items in select lists that are in the hidden weight column. You can literally get 500KB of select list items on a page that has a big menu tree for example.

Anyway in short:

• Using jQuery UI is not going to work.
• tabledrag.js could be converted to a jQuery plugin, but unless someone is going to maintain it as an independent jQuery plugin, there isn't much advantage to abstracting it from Drupal's particular use-case.
• Touch support is clearly important, that's over in #1261002: Draggable tables do not work on touch screen devices.

I'm retitling this issue to reflect the discussion that followed and marking won't fix. If anyone thinks I'm incorrect, please reopen. I think we'd be better served by improving our existing code to eliminate inefficiencies rather than pursuing a big hand-wavy issue like this.

Unmarked duplicates:
#1164804: Table rows are intended to allow dragging, but this is not clear.

That's fair enough, agreed with the won't fix.

I'll try to get something going in contrib and see what happens for D9.

@quicksketch & @nod_ the original purpose of this issue was to speed up tabledrag.js for large tables for which it is currently slow.

I personally do not care what library this uses to improve the performance of table drag, but currently on large menu's or taxonomies tabledrag.js is horribly slow in D6 and D7. This is something that can probably be improved with some JS tweaks.

I don't think the original issue was to "refactor tabledrag.js to use jquery ui" but simply speed up tabledrag.

there is a really easy soluton to the select list problem ... don't use them .. use a textbox instead .. 99% of the time nobody sees them anyway, and the 1% would need to learn to type a number in there

Added accessibility concerns to issue summary.