Unwanted scrollbar/height applied to nested splitter

[Ryan]

I can't figure out exactly why the scrollbar highlighted in the attached image is being applied. It looks to me like it stems from the css rule for .ksplitter:

.k-splitter {
    height: 300px;
    position: relative;
}

I've created a jsfiddle demonstrating the issue.

• Fiddle: http://jsfiddle.net/MgspA/1/
• Full screen result: http://jsfiddle.net/MgspA/1/embedded/result/

[Dimo]

Hi Ryan,

Nested Spltiters are automatically sized to match the height of their parent only if the parent is another Spltiter pane. In this case the Splitter has two plain parent <div>s, so the default height of 300px is assumed. Please remove those two <div>s.

In addition, please note that the same element (<div>) should not play the role of a Splitter pane and a nested Splitter at the same time, because this may cause undesired resizing behavior. You need to use separate <div> elements for panes and nested Splitters.

http://docs.kendoui.com/getting-started/web/splitter/overview#nested-splitter-layouts

Greetings,
Dimo
the Telerik team

[Ryan]

Hi Dimo,

Thanks for the reply. The reason for the two plain parent divs is because I am using one for hiding the horizontal scrollbar and the other for having an over-sized splitter to show only 4 columns at a time. I'd like to mitigate this issue first before I jump back to that problem.

I've simplified the example and have removed any unnecessary divs as well as added a div around the .column ones so that a pane is not also a splitter. I'm still seeing this problem scrollbar though. Could you point me in the right direction or update the fiddle please?

http://jsfiddle.net/xjkp9/

Thanks!

[Dimo]

Hello Ryan,

Adding a 100% height style to the .tabular-results div will do the job:

http://jsfiddle.net/dimodi/xjkp9/1/

Probably I gave you the impression that the nested Splitter sizing mechanism is fully automatic with no need to set height, which is not the case. I also updated the documentation.

If you really need those additional <div>s between the parent pane and the inner Splitter, you can put them back, but with the following requirements applied to both of them:

- they should have a 100% height style
- they should not have top and bottom borders, margins or paddings
- they should not have scrollbars

These requirements will ensure that the inner Splitter will be as high as its parent pane and will not overflow.

All the best,
Dimo
the Telerik team

[Ryan]

Now every column has a 300px height. I only want to see a vertical scrollbar when its necessary. In this case, there should only be one on column two. Adding scrollable: false to each pane has an undesired effect where the bottom of column two cannot be seen using the scrollbar. 

Scrollable false: http://jsfiddle.net/xjkp9/2/

Notice how in column two using the scrollbar you can only reach J instead of O.

[Dimo]

Hi Ryan,

This is because you have default height Splitters (300px) nested inside 221px-high Splitter with non-scrollable panes.

Regards,
Dimo
the Telerik team

[Ryan]

Ah, there we go. Thank you for the help. Adding the height 100% to each .column fixed the issue. The updated fiddle: http://jsfiddle.net/xjkp9/3/

"please note that the same element (<div>) should not play the role of a Splitter pane and a nested Splitter at the same time"

I've been doing this in my app for some time now. I haven't noticed any side effects but maybe it's just because of the way I am using them. Do you have an example of unwanted resizing behavior in this configuration?

[Dimo]

If I remember correctly, problems may occur if you start resizing something manually or trigger resize events manually.

 
Regards,
Dimo
the Telerik team