Bootstrap + DataTables-1.10.0.dev + FixedColumn-2.5.0.dev
Bootstrap + DataTables-1.10.0.dev + FixedColumn-2.5.0.dev
kalium
Posts: 2Questions: 0Answers: 0
We've recently started using bootstrap an upgraded jquery and associated plugins (including upgrading to the above versions of DataTables and FixedColumn). It completely threw out the usability of one of our tables.
The problem seemed to stem from the fact that it was entering the following if block [code]if ( $(o.nTable).outerWidth() < iSanityWidth ) [/code] on line 3403, which subsequently managed to balls up the formatting (I wasn't able to quite grok what it was trying to do).
Anyway, I saw that without Bootstrap styling present it never entered this if block and there were no problems.
After more digging I found the code that caused the discrepency in behaviour was this:
[code]
_fnApplyToChildren( function(nSizer, i) {
nSizer.innerHTML = "";
nSizer.style.width = aApplied[i];
}, anHeadSizers );
[/code]
The anHeadSizers had two elements that it traversed, and as it was modifying the cells in the second , the value returned from
$(o.nTable).outerWidth() (which is a jQuery.css() call) was becoming progressively less and less. This was not the case without Bootstrap. It turns out that removing the 'max-width': 100% style element (or setting it to 'none') fixed the problem.
I'm not sure if this is a bug in jQuery, or if this is expected and the '$(o.nTable).outerWidth() < iSanityWidth' is suppose to handle this better.
Either way, I just removed set max-width: none, as there is no reason that I know of to have it set for an X scrolling table anyway.
Is this a known problem? Has it been observed before?
Cheers
The problem seemed to stem from the fact that it was entering the following if block [code]if ( $(o.nTable).outerWidth() < iSanityWidth ) [/code] on line 3403, which subsequently managed to balls up the formatting (I wasn't able to quite grok what it was trying to do).
Anyway, I saw that without Bootstrap styling present it never entered this if block and there were no problems.
After more digging I found the code that caused the discrepency in behaviour was this:
[code]
_fnApplyToChildren( function(nSizer, i) {
nSizer.innerHTML = "";
nSizer.style.width = aApplied[i];
}, anHeadSizers );
[/code]
The anHeadSizers had two elements that it traversed, and as it was modifying the cells in the second , the value returned from
$(o.nTable).outerWidth() (which is a jQuery.css() call) was becoming progressively less and less. This was not the case without Bootstrap. It turns out that removing the 'max-width': 100% style element (or setting it to 'none') fixed the problem.
I'm not sure if this is a bug in jQuery, or if this is expected and the '$(o.nTable).outerWidth() < iSanityWidth' is suppose to handle this better.
Either way, I just removed set max-width: none, as there is no reason that I know of to have it set for an X scrolling table anyway.
Is this a known problem? Has it been observed before?
Cheers
This discussion has been closed.
Replies
Allan
I'll see if I can figure out how to recreate it in a test case I can link to.
Allan