Does not fully support column toggle

It looks like there are two complicating factors related to this:

1. Additional CSS needs to be present (https://github.com/filamentgroup/tablesaw/blob/9643340fdd520162804496356...)
2. Table headers must have the data attribute data-tablesaw-sortable-col in order to be found by the column toggle business logic.

#1 is easily resolvable. #2 could be done programmatically, conditional on the selected toggle mode, to views tables (ideally through passing data attributes into Drupal's standard Views table template (https://github.com/drupal/drupal/blob/9.0.x/core/modules/views/templates...)).

This patch (8||9) provides the additional data attributes necessary on table header rows for "columntoggle" to find applicable columns. Additionally, it relocates some of the existing CSS to ensure that it cascades in the correct order.

Automated test coverage is not yet included, but that should verify steps similar to those indicated below.

1. Create a Drupal view with "table" display that includes more than one column of data.
2. Go to /admin/config/content/responsive_tables_filter and choose "Column Toggle Mode".
3. Go to your view display and verify that there are "eligible" columns for toggling, and that they do toggle display when checked/unchecked as shown in the "Expected behavior" screenshot in the issue description.

Patch seems to fix the issue for tables generated by views, but the issue persists for tables in content.

Patch seems to fix the issue for tables generated by views, but the issue persists for tables in content.

Thanks for stating that explicitly! That was the intent with the patch -- i.e., not to explicitly modify the markup that someone has inserted into a WYSIWYG, since they may want to explicitly set each column's "priority" value. In a view, there's no way to do that in configuration via the UI, so it's safer to let Responsive Tables filter auto-increment them, as shown below.

        $variables['header'][$key]['attributes']['data-tablesaw-priority'] = $inc;

That said, I'll see if we can at the very least automatically add data-tablesaw-sortable-col to tables in WYSIWYGs when the column-toggle mode has been selected & verify whether that alone allows the tables to be minimally toggle-able.

If not, then we'll need to document the fact that content editors would need to add these additional attributes to tables they add in WYSIWYGs.

Setting this back to "Needs work".

It would be great to have this available for tables in content too. Is there any possibility of being able to set the column priority in the WYSIWYG also?

It would be great to have this available for tables in content too. Is there any possibility of being able to set the column priority in the WYSIWYG also?

I think so. I think we would just make the text format processor respect any column priorities set by content editors, and only in the absence of already-existing column priority data attributes, add default, auto-incrementing ones.

Possible to get this fix rolled out in to the module?

Yes, this shouldn't be much work to finish out. I'll commit to getting it completed & released by the end of the month.

The attached patch provides a re-roll of #3 (supporting Views tables) and adds equivalent functionality in the text format filter: when "Column Toggle" is selected as the default mode in the text format filter, or when a tablesaw-columntoggle CSS class is present on a table, the table will receive the Tablesaw "column toggle" behavior.

1. For column toggle to work properly, data-tablesaw-priority must be present on all header columns, so the text format filter follows the same methodology as in Views, auto-incrementing the priority number as the columns increase.
1. This patch includes test coverage for column toggle (and also updates the existing unit test for 'stack' to be a Functional test, so that maintaining the tests is consistent). Test coverage for 'swipe' should also be added, but that's not in the scope of this issue.

I'm going to roll this new feature into a release, since it's been some time since we've done so.