Column Misalignment with Scrolling Enabled

druegamer

There appears to be a column misalignment issue with scrolling enabled. Here is a link demonstrating the issue http://live.datatables.net/wucaquko/2/edit . I have run this scenario on the following systems and browsers:

• CentOS Linux release 7.5.1804
  
  • Chrome: Version 67.0.3396.99 (Official Build) (64-bit)
  • Firefox: 60.1.0esr (64-bit)
• Windows 7
  
  • Chrome: 68.0.3440.84 (Official Build) (64-bit)
  • Firefox: 61.0.1 (64-bit)
  • IE 11

I see varying degrees of misalignment depending on the system/browser combination ranging from all columns being misaligned to only 1 column being misaligned. I can provide screenshots of the misalignment on any of these if needed.

This type of issue is similar to issues we are seeing in our more complex tables of our application, and it is presumably to do with width calculations when scrolling is enabled.

kthorngren

I loaded the Datatables CSS (jquery.dataTables.css) and that seems to resolve the issue:
http://live.datatables.net/wucaquko/3/edit

Kevin

druegamer

Is it a requirement to use the DataTables CSS? I was under the impression that was there as a convenience.

The fix does seem to work in chrome, but it does not appear to work in either Firefox (for both my CentOS and Win7 machines) or IE 11. I am still seeing misalignments in these cases.

kthorngren

The Installation page states:

you need only include two files additional in your page:

The DataTables Javascript file
The DataTables CSS file

The fix does seem to work in chrome, but it does not appear to work in either Firefox (for both my CentOS and Win7 machines) or IE 11. I am still seeing misalignments in these cases.

Are you saying the test case shows problems with the other browsers or your page or both?

Kevin

druegamer

Ahh yes. Thank you for pointing that out in the installation page.

Yes, it appears to be that including the DataTables CSS file does not fix alignment issues for this test case in either Firefox or IE.

I've also tested this in our application and I am seeing the same results there (fixes it in Chrome, but not in Firefox or IE).

Thank you for your time, Kevin.

kthorngren

Just tried the test case with Firefox on the Mac and do see misalignment starting with the Message0 column. Its beyond my knowledge of Datatables so will leave it to @allan or @colin to help.

Kevin

allan

Add width="100%" (or style="width:100%;") to your table: http://live.datatables.net/wucaquko/8/edit .

This is required for full alignment across the table when scrolling is enabled because it is virtually impossible (/very difficult) to get a percentage value from a stylesheet, which is why it needs to be in the HTML.

Allan

kthorngren

Add width="100%" (or style="width:100%;")

Dang missed that :-)

Kevin

druegamer

Thank you both for your time!

Unfortunately, I am still seeing the same misalignment issues as before (fine in chrome, misaligned in both Firefox and IE) on my CentOS and Win7 machines, with the updated test case linked by allan.

The following is a screenshot of the updated test case on my CentOS machine, and there are similar misalignments in Firefox and IE on my Win7 machine.

I have tried configuring the setup differently such as using alternative css, messing with the widths of the table, as well as the fix above, and none seem to address the alignment issue for the 3 browsers I have been testing on.

I have even tried a few workarounds:
- Adding additional width to the table post draw mitigates the alignment issues a good deal for all browsers
- Setting table-layout to 'fixed' fixes the alignment but breaks the auto sizing (which makes sense)
- Did some patching on the datatables code directly, doing some aggressive rounding and allocating additional width to each column and table. This has, from what I can tell, fixed the misalignments, but comes with it's own associated downsides

I figured I was making a boneheaded mistake somewhere such as missing a precondition (Kevin was good enough to point out that I should be including the Datatable CSS file) or missing some sort of configuration option, but if that is the case I have yet to find it.

Thanks again,
druegamer

allan

How wide is your output view please (in pixels)? I'll see if I can replicate it by matching what you are using.

Allan

druegamer

Typically it is 1920px, bit I see misalignments on Firefox and IE (on both centos and win7) when resizing the output view to other dimensions as well.

allan

Yup - got it with Firefox at that width. Its odd that it is x-scrolling at all at that width, there is no need for the scrollbar. I guess that one of the border properties isn't being taken into account. I'll need to get back to you on this one.

Thanks,
Allan

druegamer

I appreciate it, Allan, thank you very much.

druegamer

I've gotten around to looking at this issue again and investigating potential fixes. I have a patch that fixes all alignment issues in my local testing on all three browsers I listed in the original post. I'm sure there are concerns that are beyond my use case and test cases that I am not thinking of but there is at least a proof of concept here.

With this patch I make the following changes to the _fnScrollDraw function:
1. Use the same width measurements as the static measurement done in _fnCalculateColumnWidths ( ceil(bounding) - borderAndPadding ) instead of the css('width') call currently being used
2. Apply explicit widths to wrapper divs in hidden header and footer (in addition to the already applied width to the cell)
3. Wrap the actual header and footer cell content in wrapper divs and size them appropriately

The goal of 1 above is to just provide some rounding. This also uses the same measurement as the static sizing, providing some consistency between measurements, and could allow the sizing in general to be spun out to a separate function which both could use.

The goal of 2 and 3 is to improve consistency. Wrapping both the header and footer table cell content in divs allows for the table layout algorithm to apply more consistently across all tables involved (these are currently being removed/added on each _fnScrollDraw call but potentially these could made more permanent to reduce the performance hit). Additionally, applying widths to the wrapping divs provides a more concrete width to the cell content (instead of letting the table layout algorithm mess with it).

Hope this is of some help!