Table creates excess height under some circumstances

[JustASquid]

Description

The table seems to be creating a lot of excess height, well beyond the rows that are in the table. The only way to workaround the problem (that I have found) is to put the table in a container with a fixed height - but that workaround won't work for my application as the table needs to allow for dynamically added rows.

Notice in the above image that the height of wtHolder is being explicitly set to 1223px, which is much higher than the table needs to be. We don't specify the table height anywhere as it is intended to have dynamic height.

What could be causing something like this?

Your environment

• Handsontable version: Older, but latest version exhibits the same behaviour
• Browser Name and version: Chrome (latest)
• Operating System: Windows 10

[AMBudnik]

Hi @JustASquid

thanks for sharing. I guess I saw the same issue somewhere on our board however I'm not able to find it.

[GMNGeoffrey]

+1 I'm also having this issue. I would like to be able to place multiple tables on the same page in a list, with each one taking up the height it needs and the page scrolling if necessary to display all the tables. The first table takes up the entire page and the second is not even visible.

Is there any workaround you know of?

[AMBudnik]

Hi @GMNGeoffrey

if you have fixed width columns it won't be hard to do - worse if columns are adjusting their width to the content.

[GMNGeoffrey]

Hi @AMBudnik,

Thanks for getting back. I can make my columns fixed width if necessary. I'd like to be able to have a variable number of rows, however. I can do something hacky involving giving the rows fixed height, looking at the number of rows and multiplying by the height and then using that to determine the height to give the element, but I'd prefer to avoid that if possible. Why does the HOT stretch to take up more space than it needs? Also when there's another HOT below it, why is it completely hidden instead of allowing it to be seen with vertical scrolling?

Thanks!

[JustASquid]

I'm also in need of a workaround. The fixed rows height multiplied by number of rows hack is definitely not ideal.

[JustASquid]

@AMBudnik Any tips for a workaround here?

[AMBudnik]

Hi

If you do not define height and width for the Handsontable container it should take in height just the space needed to display cells and 100% of width available by the parent element. Even when we add and delete some rows or have multi-line cells.

Can you share a demo where the width of the Handsontable container is bigger than it should @JustASquid ?

[TuWebO]

Hello,
Thanks for this work. It is also happening to me every time I click on colum's header for sorting.
columnSorting: true
I don't know if this gives any clue. I've just started to use the plugin.

[AMBudnik]

Hi @TuWebO

thanks for joining the subject. Can you guide me how to replicate the issue?
I tested this demo http://jsfiddle.net/03hmu5du/ and sorted it a few times but the htHolder and the DIV that holds the instance did not change in height.

[TuWebO]

Hi @AMBudnik,
Thanks for the fast response.

Ok, I'll try to show you.

Something like this in your jsfiddle:

HTML

<div class="main">
<div id="example1" class="hot handsontable htRowHeaders htColumnHeaders"></div>
</div>

CSS
Add before your code

.main {
  overflow: hidden;
}

JS

Remove line

height: 330

I also should have red (better) the documentation.

Thanks for your time.

[AMBudnik]

Thank you @TuWebO I have replicated the issue.

Updated demo: http://jsfiddle.net/k8zzf4j6/

[TuWebO]

Hi @AMBudnik ,
Yes, you got it!

Thanks for the fast response, hopefully this will give some clues... let's see.

[dborisog]

#4607 may provide additional insights into this issue.

Copying the relevant comment.

Looking at the handsontable.min.css having .htCore class for table tag, it seems to me Bootstrap is mostly irrelevant to the 4607 issue. However, if not collapsible, there handsontable works perfectly by not covering the content below the handontable, very much unlike if Bootstrap collapsible. In my eyes, it means that for one case of these two the height processing is done right, maybe at initialization of the table, and in the second bootstrap case the processing is done somehow differently.

I'm however a novice in front-end development and do not understand CSS processing specifics, meaning that the non-collapsible case working right is not the handsontable JS doing, but the browser's doing.

[AMBudnik]

Thank you for your effort to share it @dborisog

edit: (inform Gr # 11205)

[lsukharn]

I have the same issue - table height increases with horizontal scrolling. I tried the newest version of hot, 0.34 I believe, and 0.16.1 - got same problem in both cases. Is there a solution to it?

[AMBudnik]

Sorry, in the latest version in behaves the same way.
We will try to investigate this a little bit closer next week.

[lsukharn]

So far I was able to fix the issue with:
autoRowSize: true,
viewportColumnRenderingOffset: 100,
(you need autoRowSize pluging, which should be in your plugins folder)

the whole object is created as:
$some_name.handsontable({
data: current_data,
colHeaders: current_colHeaders,
columns: current_cols,
startRows: 1,
autoRowSize: true,
viewportColumnRenderingOffset: 100,
sortIndicator: true,
maxRows: current_data.length,
columnSorting: true
})
the solution still looks a bit hacky to me...

[AMBudnik]

I just got an update from our devs team. We have investigated the issue and the reason the table behaves like this are the settings.

If any container between thedocument.bodyand the Handsontable DIV element has an overflow: hidden attribute it needs to have a fixed height.

More information about the container behavior at our blog post https://handsontable.com/blog/articles/a-complete-guide-to-changing-size-of-handsontable

[bchoddny]

It is not easy to enforce the condition that all containers between body and handsontable div need to have a fixed height.

[bchoddny]

A complex form that has too many fields, in addition to handsontable, the outermost container need to have overflow as hidden.

[AMBudnik]

It is not easy to enforce the condition that all containers between body and handsontable div need to have a fixed height.

I completely agree. One library should force you to change anything else in your project. The overflow case is just something that we cannot change. Switching from pixels to fluid values is, of course, in our plans, however, as it is a very long and complex process we want to fix some quick but important issues before taking our hands on the pixel task.