Column mis-alignment

dhumph

Hi, awesome plugin! I'm having problems with column alignment in different browsers. (ugh..stupid browsers!)
Firefox looks awesome, but IE and Chrome are wrong. All my tests on on Windows.
Wondering if you have any suggestions how to fix/avoid this. Here's my example.

1. goto www.simplecardsort.com
2. Click on "Demo" in the header
3. Click on "view results" (under movie categories)
4. Change the "table type" to "Groups X Card".

allan

Can you try the 1.8 beta please: http://datatables.net/download/ ? I've made some changes to how the column width calculations are done, particularly when x-scrolling.

Allan

mirkec

I'm using 1.8 beta2, and experiencing same problems when I apply sScrollY. I't doesn't matter if scroll is visible or not, columns are slightly misaligned.

dhumph

Hi Allan,
Thanks for you quick response.
I've downloaded the 1.8 beta and placed it on my server. From what I can tell there isn't any difference in my situation. Is there anything I can do to help debug this? Thanks.

David

jschrantz

I am having a similar issue, but when I click on any of the column headers to sort, the widths fix themselves and I have no issues after that. Firefox is perfect, IE and chrome are slightly misaligned. I am using sScrollY and the cells in the header and footer seem to shrink to the size of the body cells. Using 1.8 beta 3 and like above it doesn't matter if the scrollbar is visible or not. It is not a killer bug, but I would love to see a solution. Thanks in advance for any input.

allan

I suspect the "thing" that is triggering this issue is the border-collapse: collapse on the table - but I'll need to do a bit more investigation. The border-collapse: collapse can make the the browser caulcations slightly funny. The other thing that it might be is sub-pixel rendering. Since in Javascript you can only set int values for width but the browser can sub-pixel render widths when calculating them... It's a little bit of a minefield :-)

Allan

allan

Okay - it was in fact option 3 :-). This is a problem I've encountered myself in the past and it's quite frustrating - basically what is happening is that DataTables, when calculating the widths that the columns should be looks for the longest string in the table for each column and then constructs a "worst case" table from which it can read the sizes. The problem is with the "longest string" part. For example "mmmm" takes up a lot more space than "iiiii", but DataTables would pick the latter. I did experiment with getting it exactly right in the 1.7 betas, and that was perfect, but also unbearably slow in IE (and thus had to be removed) - the code is still in there if you are interested in trying it, just not executed (although now removed completely in the 1.8 series).

So as I mentioned I've hit this problem myself and I added an (currently) undocumented feature to DataTables to help with the problem. A parameter called "sContentPadding" exists for columns which is a string that will be post fixed to the content in the 'sizing' table.

For example in your table you can add:

[code]
"aoColumnDefs": [
{ "sContentPadding": "mmmm", "aTargets": ["_all"] },
{ "sWidth": "150px", "aTargets": [0] }
]
[/code]
to your initialisation code and that should to the job. In this specific instance I think it's the word "Independence" which is tripping up the calculations. DataTables picks a much longer string for that column, but that string can be broken up while "Independence" cannot. I've added a width to the first columns as will to help this a little - not really needed might might be useful. One other thing you can do is add "white-space: nowrap;" to your CSS for TH and TD cells - which you might or might not want to do.

So basically this is a work around for a known issue in DataTables. The real fix is to use pixel perfect calculations - but sadly that has proven to be exceptionally slow in browsers :-(

Regards,
Allan

dhumph

Allan, thanks for digging into this. I'll hopefully have some time on monday to give this a try and see how it works.

On a side note, I'm curious how you arrived at using the text to size the table. Not having tried to do this, I would instinctivly approach it by letting the table size it self, then record the size of the columns, then recreate the header with those sizes. (at the same time fixing the size of the table columns). Is this approach flawed? or does it break down when it's combined with other features?

David

allan

You are quite correct - the perfect case would be to let the browser just size the entire table for you, and this is what DataTables will do under certain conditions - but when those conditions fail the method I describe above is used as a fallback. To have the table as a whole used you would need to render the entire table - which is bad news if you are using anything more than say 500+ rows and virtually impossible if you have 1 million+ rows (due to speed). Also it requires all of the data to be available so server-side processing would be out, as would the new deferred rendering. So this fallback method is required and sadly it's not quite perfect.

If you are interested the function in question in DataTables is called _fnCalculateColumnWidths. You'll be able to see there the conditions that are placed upon using the original table and the automatic calculation one.

Allan

neags23

This appears to be my issue exactly.

Did a fix ever turn up for this? My client has literally spent thousands of dollars for me to bang my head on the keyboard trying to fix this, and I have nothing to show for it.

In my case, if I don't try to limit the width of the table, alignment is fine. Any time I constrain it, the misalignment happens.

pholord

I've fixed this issue by the following way:
1) Added ".dataTables_scrollHead table{ table-layout:fixed;}" style;
2) Surrounded all content in my table cells by tag. Like that:

[code]function gridRenderer(oObj) {
var column = oObj.iDataColumn;
var columnAnchor = oObj.oSettings.aoColumns[column].mDataProp;

var content = oObj.aData[columnAnchor];

if (content == "null" || content == null) {
content = "";
}
var result = ""
+ content + "";

return result;
} [/code]- function

and

[code]"aoColumnDefs" : [ {
"fnRender" : gridRenderer,
"bUseRendered" : false,
"sContentPadding" : "W",
"aTargets" : [ "_all" ]
} ] [/code]- attribute ro the table deffinition

For me it was enough to make it work correctly.

pholord

Forgot one thing - "bAutoWidth" should be true.

allan

@neags23: Can you post a link to a test case please. You could also hit the 'support' button with some of those $ ;-)

@pholord: Nice use of target _all :-).

I think I'll promote sContentPadding to a fully documented option and hopefully put a suitable demo together as it is very useful.

Allan

pholord

I guess I did not made myself clear. sContentPadding does not help at all. At least at the IE8 browser. I've just forgot to remove it from my example.

I am newbee in JS and HTML and I can not explain it, but misalignment was fixed only after I surrounded all content to the "span" containers and added style I specified above. So sContentPadding is only an artifact remaining from my unsuccessful experiments.

By the way, what is wrong with target _all?

Sorry for my poor English.

Best regards.