FixedHeader on DataTables which has columns width defined doesn't work
FixedHeader on DataTables which has columns width defined doesn't work
bijoy.anupam
Posts: 10Questions: 1Answers: 0
Not sure if I am doing soemthing wrong, or not. After lot of searching around, couldn't find working solution to the problem I am facing. Not sure if FixedHeader library is non-compatible or it is not handled properly. In any case, please do help.
When I scroll down, the column width shifts a little. And when I scroll back top to initial position, the columns width are all gone, and it looks like it defaults to autowidth. I am using columns width for some of the columns. Ref: https://datatables.net/reference/option/columns.width
I tried using autoWidth: false as mentioned in some of the related discussions, but it doesn't work. The width gets reset, when we scroll the page. Is it something which i miss?
Please check the fiddle link: https://jsfiddle.net/bijoyanupam/9787cfhy/
This question has an accepted answers - jump to answer
Answers
The problem appears to be that you have 130+100+70+30+60+70 (=460) as the column width - but
width="100%"applied to the table in the HTML and CSS. 100% width doesn't == 460px with my window.Hi @allan What if in the example, I use 130+*+70+30+60+70, where * has no width defined. Check the updated link: https://jsfiddle.net/bijoyanupam/9787cfhy/
It would still create problem. The inline styles gets removed when we scroll back up. Even the percentage width doesn't work.
If you leave
autoWidthenabled it appears to work as expected.Allan
Thanks @allan you have answered the question, it solves the problem. But, I needed the https://datatables.net/reference/option/autoWidth option because I had a responsive issue on resize.
Now, I am stuck...
Please link to a test case showing the full issue so I can debug it.
Allan
Looks like using width: 100% in table solves the responsive problem I had. Thanks for the help @allan . Highly appreciate.
@allan I ran into some width misalignment issue. Looks like if I use
box-sizing: border-box, the width of the header mis-aligns, calculating the width value to be something different from whats already assigned in style attribute.After I remove the box-sizing (though entire table has to be updated), the table header mis-alignment is corrected but it is still off by few pixels, and corrects itself after multiple scroll.
How can I handle?
PS: I did a small edit in the library at the method
_matchWidths()where I changed the way width is calculated in thegetasreturn $(this).outerWidth();instead ofreturn $(this).width();. It does solve the misalignment problem, and I don't have to removebox-sizing: border-box. But, it breaks forbox-sizing: content-boxIf at all we could use the base table's properties as is, like classes, width style attributes without re-calculating width again, this would have been simplified and may be solved the mis-alignment issue.
Yes - the table cells need to be content-box. I hope to improve that in future versions, but in the past I've found that it makes the calculations quite difficult due to browser variations. That might have improved in recent times.
Allan
@allan I get out of one, and run into another problem...
I use fixedHeader.js in combination with dataTables.responsive.js and when the fixedHeader is shown when I have scrolled down, and resizing the window vertically changed the widths of the columns, hiding one as responsive with the + button.
When I resize the window vertically with page scrolled up, everything works fine. What could be the problem here?
Could you link to a page showing the issue please?
There is an example showing FixedHeader and Responsive working together, although a slight quirk due to the responsive nature of this site I wasn't aware of before...!
Allan
@allan The link you shared is the perfect example of the issue I am facing.
Steps I followed:
Scoll down until you see the fixed header on the table, and now if you vertically resize the window, you will observe some of the columns got hidden as dropdown of (+) - the usual responsive behavior when we resize the window horizantally.
I have observed it only on Mac/FF. On Mac/Chrome, Mac/Safari, Win/FF & Win/Chrome it seems to work fine.
I'm afraid I'm not seeing that issue with FF Mac. I do see the FixedHeader scrolling off the screen too earler because it hasn't been recalculated for the new height of the table after the child row has been shown. That is something I need to fix.
Allan
That's strange @allan, i can replicate it everytime on my Mac (Yosemite)/FF (latest version, 48.0.1). Hope the steps I explained are not confusing. I did check with few of my colleagues with the same configuration, it can be replicated.
Ah yes - I did muck it up earlier. Not sure why that is happening I'm afraid. I'l try to make time to look into it before the next release of Responsive.
Thanks for letting me know about it.
Allan
@allan Thanks for your time. Will wait for the next release of Responsive plugin. Until then, I will release my work as Known Issue. Apprieciate again for the all the help.
@allan Over the time, on testing... we found out that... if we keep scrolling top and bottom many a times... some of the column widths keeps shrinking and the fixed header always has some mis-alignment with the table borders.
On this link? I don't see that issue there I'm afraid.
Allan