Was there some kind of resize changes that got added around the same time as the Column Control?
Was there some kind of resize changes that got added around the same time as the Column Control?
REJIS
Posts: 38Questions: 5Answers: 0
I started playing with the column control around DT 2.3.2, and noticed the columns and/or table doing this weird resize process on page load and when filtering. It almost looks like it is reading/calculating the width of every item in every column and adjusting sizes as it goes. The table and column width changes up to 8-10 times at like half second intervals.
At first I thought it was the column control's filters. I waited until it got updated and just downloaded everything again today, and it still does it. Even on tables without any Column Control when they load it readjusts itself for a few seconds. No AJAX calls either. It is just data local in the table. I have one page with two tables side by side- one has like 130 rows and the other a little over 1000 with each showing 15 rows at a time in pages. When the page loads the tables go nuts with one getting bigger and one getting smaller. It takes 3-5 seconds for them to stop sizing and settle, and is really annoying. Sometimes the columns will jump in size 10-20 pixels, and towards the end of the process it seems to adjust 1-3 pixels in size.
This question has an accepted answers - jump to answer
Answers
Can you give me a link to a page showing the issue? There was a change in DataTables 2.2.0 to do automatic column resizing when the width of the container changes. Perhaps that is what is causing problems here?
Allan
I made a video showing it sizing when I type in the filters. Hopefully it lets Google Drive links post here. https://drive.google.com/file/d/11nVl24et8KWhCJprmYegZd8t7yRbrVyq/view?usp=drivesdk
Seems very likely that it is the change in 2.2.0, but I'd need a test case showing the issue really. Have you tried setting the container to a fixed size (it might be, but I'm not sure without a test case
).
Allan
Likely just uses Bootstrap's Flexbox type layouts. Pretty much everything is in row and col classed divs. Looks like DataTables adds a style to my table tags setting them to width 100%. Are you saying a container needs a pixel size set? Which container too? The table tag seems to get wrapped in other dt div tags from layout. Some tables are in div tags that are just display block which would take up the full width of the browser. We usually stay away from putting the tables in divs or panels that are a fixed width because the tables tend to overflow outside the bounds of the parents and look weird.
My gut feeling is that DataTables adjusting its column widths is growing the container a small amount for some reason. That then causes DataTables to adjust its column widths, which ... [cycle].
It shouldn't cause the layout to change, but something is causing that (if I'm correct), and I'm not sure what.
Allan
That sounds accurate. I've been playing with things a bit. Usually where we define columns I have some classNames on all but 1-2 columns setting a width for the small columns that are 50-100 pixels and we let the description type columns grow. It seems to honor that and when it resizes it adds a width style to all the colgroup columns only updating the one without the classes setting width. When I take off the width classes it adjusts all 5 colgroup columns 25-28 times each (I count all the flashes of the changes in the DOM Element list). The immediate div parent of the table I set to a 700px width and it just sizes them all once at load. Decimals up to 3 places of px width (Totals 700.0005, so likely a decimal getting you). When I uncheck the width of the div it goes crazy adjusting all the columns 20+ times each again.
The question then, is why is it causing the table to redraw slightly wider. I'm afraid I would need a test case showing that to be able to try and diagnose the issue.
Allan
How do I make a test case? None of my pages are accesable to the public, and I don't have a web host of my own anymore. It does this on pretty much every page I put this version on. I'd think a lot more people would be seeing this.
Start with this technote:
https://datatables.net/manual/tech-notes/10#How-to-provide-a-test-case
If you want to use ajax loaded data you can use one of the templates found here:
https://datatables.net/manual/tech-notes/9
Probably the key thing is to replicate the Bootstrap environment and styling that you have to try replicating the issue.
Kevin
I would need to somehow load Bootatrap 4.5.3 on one of those test sites. I've been trying to emulate it on one of the columnControl Example pages. It lets me pick Bootstrap 4 to render with there, but every layer of the pages here specifies a width in pixels or percent. I can't get it to do it on the pages here, but on all of my pages I can remove all other styles and classes and just have basic Bootstrap row and col classes and it does it. I'm still messing with it trying to figure out this magical combination. Sounds like the Resize code just needs to round down and strip off the fraction of a pixel...not sure why it needs to specify a width out to 3 decimal places of pixels.
Use the Download Builder to get the proper Datatables code for Bootstrap 4. You can select Bootstrap 4 in step 2 and change the URL to load BS 4.5.3 instead of 4.6.0.
Kevin
Because if I round it down, the column widths don't add up to 100% and we get column misalignment.
Column width control is easily the most complex part of DataTables. You'd think it would be easy, but it really really isn't! It would probably save about 10KB to strip all of that stuff out as well!
This thread was opened over night, which appears to be basically the same issue? Do you have scrolling enabled as well?
Allan
No scrolling enabled. Seeing your last comment I did try it in other browsers. I have been using Chromium Edge. I tried Chrome and Firefox and the same resize cycle happens in them. I'm still trying out things on my end. The scrolling gave me an idea- Our pages are a sort of 3 row Flexbox layout too with Header and footer on top and bottom with the body in the middle filling the rest of the space. The body section does have its own scrollbar to scroll the page content, and usually there is no browser scrollbar. Maybe if your code is looking for a scrollbar width on the browser or document/body level it isn't seeing it.
As a test I changed overflow to not scroll. The resize still happens, but it is almost made worse now and keeps sizing like 1 pixel for 2-3 more seconds.
It doesn't. It will look for it on the DataTable body container when scrolling is enabled, but not elsewhere.
Allan
Got put on something else for a couple weeks, so didn't get to dive more into this yet. I saw version 2.3.4 was released, so I updated to it...but it still does the resizing weirdness.
I guess my next question is...what was the reason for the resize change? Was it required for the Column Control or to fix a bug? Can it be pulled out to a Resize component that I can unselect when building the download? I didn't have issues with the previous way, and the change is distracting, so just seeing if there is a way to turn it off?
Unfortunately I didn't get a chance to look into the resizing issue you were seeing before the 2.3.4 release - sorry. It is on my list of things to do though.
Nothing to do with ColumnControl. The idea was for it to be a convenience. Previously if the container for the DataTable changed size then you had to call
columns.adjust()to have it recalculate the column widths. That appears to work in most cases, but in yours, for some reason, the act of resizing the table causes the container to adjust, which causes the columns to adjust, which... (loop).This is the code that triggers that behaviour.
You can use
autoWidthand set it tofalseto have DataTables not attempt to calculate the column sizes.Allan
I've been working on this today (it has consumed the whole day in fact), and I've got a much better idea of what is happening.
The tl;dr is, could you try the nightly version and see if that helps address the problem for you?
I'm not certain that it will address the issue you are seeing (no test case provided), but there is a good chance it will. The fix isn't perfect, so there is also a chance that it might not!
The long version - DataTables creates a "worst case" table that it uses to calculate the column widths. When the table doesn't have a fixed width container, such as (I think) in your case, it makes the column width calculations critical.
The worst case table uses the longest strings from each column - however, that isn't always the widest content due to variable character width and kerning. This means that the column sizes applied might not be right, depending on the content shown. Since the sizes are not recalculated for a page / length change (it already thinks it has the correct sizes across all pages) the second draw content overflows, and thus causes the container to resize and the recalc is done. Eventually it does hit the right size.
My solution has been to try and capture more strings that force column width, which gives it a better chance of not having problems with variable character width.
As I say, if you could try the nightly please, and let me know how that goes. If it works, great. If it doesn't, please link to a test case so I can debug it directly.
Allan
I've made one more commit which now fixes this issue as far as I am aware. This is an update which is running the nightly build, from the test case I was given in the other thread.
Hopefully this will fix the issue for you as well. Let me know
.
If not, please provide a test case.
Allan
No change with either nightly build. It goes away when autoWidth is false though. I'm still trying to figure out what class/style is causing it, and will update you when I find it.
I also notice something weird happening with 2.3.2, 2.3.4, and the nightly while testing this- One of the primary reasons for using the recent builds was for the Column Control. Previously I had put my own inputs in the footer of the table, and on an input event I would search/filter the column. The Column Control did this and allowed for selecting contains/equals/starts with/ends with, etc. I started replacing what I had in the footer of each column with the Column Control version. It worked great, but now it seems to not respond when I type into it. I have to click the x to clear it, and then it is like it initializes and starts working filtering my column. I have to do this for each column now, clicking the x to clear for it to work. I didn't have to do that when I first started testing the Column Control.
Hi,
Sorry to hear that the nightly hasn't fixed the issue. If you can link to a page showing the issue, I will hopefully be able to investigate.
With the ColumnControl issue - I'm afraid I don't know what would cause that. I've just double checked the examples and they appear to be behaving as expected. Again, if you can provide a link to a page showing the issue, I can take a look.
Allan
I made a video showing the filter issue. I hit F5 at the beginning and end to show the resize weirdness again too.
The footer filter is just created with columnDefs targeting the columns and using a target of tfoot with a content of [“search”].
https://drive.google.com/file/d/1sbsy0LJxh2IV5Qt9Yum7xaJrTSjcR9V5/view?usp=drivesdk
I think I may have found the thing causing the resize issues-
Page is Bootatrap 4.5, and there is a div tag parent with a class of d-flex that is a Bootstrap class that sets display to flex. It also has a class of justify-content-center to center the content...but it doesn't seem to make a difference and the resize weirdness happens either way. That div only has one div child that is a panel class (Kind of like a card class with header and body classed div tags). Everything else is in the body div of it- User search form, Advanced User Functions card, and the table.
If I take off the d-flex class on the parent- no resize weirdness.
Also, I just noticed when playing the footer filter video that the Clear Search button isn't detecting anything typed and enabling itself until the x is clicked too.
That's interesting. Thanks for digging into it. If you could link to a page showing the issue I can see what I can do about it in DataTables.
Allan
For which part? I don't have a public host to put anything on and the live datatables doesn't have the configuration needed along with it throwing a bunch of errors in the console for what it does have.
I plan on just using autoWidth to turn that off. The search/filter not working I'm not sure what to do. I know I have had it working, so maybe it is how I'm using the ColumnControl for the header sort and the footer filter at the same time that it isn't liking. I may just have to revert back to the old code and not use the Column Controls even though they were a good idea. I'm getting a weird behavior now too when the select checkbox is allowed in the header it is showing a little square in my Select All button when the indeterminate state shows. Possibly related to the CSS position it uses within a table. I had a similar issue with jQuery Validation errors on inputs shown in a table- some positions require a parent to position off of, so I had to set the td tags to position relative when an error is shown on an input within a table to keep them in their cell, otherwise it would position them within the entire table putting them in the upper left corner like this is doing to the indeterminate state.
Possibly the errors are due to not loading the JS libraries in the proper order. Post a link to your test case and we can try to help get it running.
Kevin
If you can't link to your own page, you can use https://live.datatables.net/ , JSFiddle, StackBltiz or one of many other similar services to create an example showing the problem so that I can try to debug it and help resolve the issue you are seeing.
Allan
Ok. Made a fiddle with as much copied over as I could. Couldn't replicate the resize issue or the filter. Looks like our UI person messed up the checkboxes in the header. Nobody likes the goofy looking graphical checks, so she was overriding them and looks like she missed the dot you guys also render over the dash. A lot of the other floats are to position the dom specified layouts the way version 1 did for tables we still have not using the new layouts. Maybe what is there can give some clues as to what could be causing it in the full pages. Or at the very least gives ideas on what should have been in version 2 so dom layouts still worked and didn't break making the need for all the extra CSS. I'm sure it is probably something we had to do to make version 2 work with dom that now breaks the resizing.
https://jsfiddle.net/cdbhLw72/
I may have to go over the CSS with our UI person too since it appears it was modified from what I said was needed. It should have only targeted the ones in the divs from the dom layouts, but looks like she has a lot of them targeting more than one including the controls in the new layout divs that don't need floats. I can't stand floats in general and wish they would have used at least a Flex layout to accomplish it. We have almost 10 years of code, and converting all the dom to the new layouts would take away too much time from the conversion that was supposed to take 3 years.
Yes, if you have tons of custom CSS for the legacy class names such as
dataTables_wrapper, which does appear to be the case, then you'll need to update the CSS. I see that you've already got selectors that would work for both DT1 and DT2 - e.g.Allan
It wasn't really custom CSS until DT2. DT1 would position controls defined in dom certain ways. Search and Pager on the Right, Length and Info on the Left. When we went to DT2 everything was just stacking. DT2 probably should have just translated dom to layout. The examples for layout even have them flowing how dom did.