Behavior of columns.adjust() in DataTables 2.0.2

mrfredricksen

Link to test case:
https://live.datatables.net/yazodogo/6

Debugger code (debug.datatables.net):
N/A. I tried running the debugger upload on the test case, but encountered two errors:
1. "Uncaught TypeError: table.oInstance.fnGetData is not a function"
2. "Uncaught ReferenceError: remoteWindow is not defined"

Error messages shown:
N/A

Description of problem:
I have been working on upgrading DataTables in one of our projects from 1.13.6 to 2.0.2. In our projects, we sometimes use our own jQuery plugin that adds grouping to rows within a table. It's similar to DT's RowGroup extension, but has additional features and can be used independently of DataTables.

In DataTables v1, we have had success using DataTables and our custom plugin simultaneously by loading DataTables first and our plugin second. That order is important because 1) the inserted group header rows do not represent actual records (and therefore are irrelevant for row count, filtering, etc.), and 2) the inserted group header rows often contain a colspan, which is incompatible with DataTables.

Sometimes we have the need to adjust the column sizes of a DataTable after the table has been initialized. This could be due to modifying a row's content, showing a table that was previously hidden, etc. We do this via $.fn.DataTable().columns.adjust().

In DT-1.13.6, adjusting columns on a table bound to both DataTables and our plugin worked fine. In DT-2.0.2, it appears the first group header row is throwing off the calculations - presumably due to the colspan. If I interpreted the source code correctly, DT-1.13 calculated column sizes based on header columns, while DT-2.0 calculates column sizes based on the columns in the first row in the body. If true, that explains the difference in behavior. Note that this appears to be an issue specifically when scrollX or scrollY is used. We use scrollY on nearly all of our DataTables.

I have created a simple test case that shows an example of this scenario. It is not actually using our custom plugin, but simply binds DataTables, inserts a few group header rows containing colspans, and readjusts the columns. I have two versions of the test case, with the only difference in code being the use of scrollY:
--Without scrollY; columns sized correctly: https://live.datatables.net/yazodogo/4
--With scrollY; columns sized incorrectly: https://live.datatables.net/yazodogo/6

There's probably good reason for the change in calculation logic, and there's no particular reason you should need to make things work specifically for a plugin completely dissociated from DataTables. But perhaps others will run into sizing issues in their unique situations. Do you have any suggestions that could alleviate this? For example, if there was a way to provide a CSS selector to DataTables to tell it what types of row are eligible (or ineligible) for column size calculations, I could exclude any rows that are group headers, forcing it to choose a 'real' row to calculate from. Or perhaps DataTables could automatically exclude any row that wasn't present when the DataTable was initialized.

Let me know what thoughts you may have. And thanks for all your great work on this plugin!

allan

So there seems to be a problem with the browsers and the use of colgroup to set the width of columns, when the first row in the table contains a colspan. I feel this is a browser issue, but both Firefox and Chrome do it, so I'm going to have to dig into their algorithm for table widths and try to figure out what is going on.

At the moment, the workaround is to have a row at the top of the tbody which does not contain a colspan. Sorry I don't have a better answer at this time.

Allan

mrfredricksen

Thanks very much, Allan. If you do end up making any changes that relate to this, I'd love to hear about it. But I also realize you've got plenty of other things to do besides fixing browser issues for edge cases.

allan

It needs to be done - you aren't the only one to have tripped over it. I will be looking at this in up coming bug fix releases.

Allan

mrfredricksen

Sounds great. Thanks very much!