Kendo-Splitter: how to rearrange pane sizes after browser resize and to keep separate scroll bars

[Michael]

Hi,

I have a kendo-splitter with two horizontal panes with large content. After page loading, when I resize the browser (half the width), the behaviour is as expected: each pane gets its own horizontal scrollbar.
However, if once resized by the splitter bar, the pane width is not longer adjusted after browser resize events. Instead, the page shows a single scrollbar for the whole splitter.

I understood from a similar JQuery thread (https://docs.telerik.com/kendo-ui/knowledge-base/keep-pane-size-in-percentages), that this is expected and that I have to rearrange the pane sizes programatically.

Is there more recent angular sample code for this approach, our could someone kindly layout the most effective way (avoid flickering etc.)?

As an additional question : How do I achieve separate vertical scrollbars for the panes? The pane contents have different size. When changing the height of the browser window, I get one vertical scrollbar for the whole splitter. However I would prefer separate vertical scrollbars for the panes.

My sample component code is placed below, toghether with two screenshots of wanted / unwanted rendering.

Thank you!

import {Component} from '@angular/core';
import {SplitterComponent, SplitterPaneComponent} from '@progress/kendo-angular-layout';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [SplitterComponent, SplitterPaneComponent],
  template:
    `
      <div class="container" kendoWindowContainer>
        <main>
          <kendo-splitter style="height: 100%">
            <kendo-splitter-pane [collapsible]="true">
              <div class="pane-content" style="height: 500px">
                <h3>Inner splitter / left pane</h3>
                <p>Resizable and collapsible.</p>
              </div>
            </kendo-splitter-pane>

            <kendo-splitter-pane>
              <div class="pane-content" style="height: 700px">
                <h3>Inner splitter / center pane</h3>
                <p>Resizable only.</p>
              </div>
            </kendo-splitter-pane>

          </kendo-splitter>
        </main>
      </div>
    `,
  styles: `
    .pane-content {
      padding: 0 10px;
      border: black 1px solid;
      width: 600px;
    }

    h3 {
      font-size: 1.2em;
      margin: 10px 0;
      padding: 0;
    }

    p {
      margin: 0;
      padding: 0;
    }
  `
})
export class AppComponent {
  title = 'test-kendo-splitter';
}

[Zornitsa]

Hi Michael,

Thank you for the additional clarifications and screen recordings provided.

Based on what I understood, it appears that the described scenario is identical to the second version of the bug reproduction explained in the following bug report in our public GitHub repository:

• https://github.com/telerik/kendo-angular/issues/4369

In this line of thought, just to be sure, please observe the information in the above item and confirm whether the Splitter use case on your side, in which the issue is replicated, is the same as the one described in the bug report. 

In case the use case is indeed the same, I am happy to inform you that a fix for this bug has been released in one of the develop versions of the Layout package - v17.0.0-develop.12. Therefore, I would suggest updating the Layout package to the mentioned version in order to benefit from the available fix for the problematic behavior.

With the above being said, I am linking below the StackBlitz example that was previously provided by my colleague Martin, using the v17.0.0-develop.12 version of the Layout package for observation of the Splitter's behavior:

• https://stackblitz.com/edit/angular-w4pkzb-iagyud?file=package.json

On that note, I tested the behavior of the Splitter resizing in the above example by performing the steps described in your reply and I can confirm that it is no longer reproducible with the mentioned develop release. 

Please observe the provided information and let me know if it is applicable to your scenario as well.

Regards,
Zornitsa
Progress Telerik

[Michael]

Hi Zornitsa,

thank you for your research and the proposed fix!
It completely solves the issues I have had with my code.

Do you know by any change whether we can expect the release version 17.x.x including the fix with the 2024 Q4 Release (scheduled for November)?

Also worth to mention:
We did not pass an input "size" to the left pane in the example. This leads to following behavior:

- Initialy, the panes keep their percentual width on screen resize
- As soon as the splitter bar was used once, the left pane keeps its absolute size on screen resize.

This might appear unexpected.

If a size is given to the left pane however, the behavior is completely predictable. After screen resize, the left pane keeps its size by ratio or absolute, depending on the unit given with the "size" input.

Regards
Michael

[Zornitsa]

Hi Michael,

I am glad that the mentioned bug fix has resolved the issue on your side as well.

Indeed, I can confirm that the fix for the Splitter resizing bug will be included in the next major release of Kendo UI for Angular, i.e. the 2024 Q4 release which is scheduled for November:

• https://www.telerik.com/support/whats-new/kendo-angular-ui/roadmap 

Regarding the additionally described behavior of the Splitter that a fixed size is being set to one of the panes after resizing them through the splitter bar, I want to clarify that this is an expected behavior of the component. To be more comprehensive, we have an internal logic that sets a fixed size for one of the panes when no initial size is specified and leaves the other pane to be further resizable. 

I hope the provided information sheds some light on the matter.

Regards,
Zornitsa
Progress Telerik

[Martin Bechev]

Hi Michael,

Thank you for the provided details.

I reused the shared code snippet and created a runnable StackBlitz (that uses the latest package version in Angular 18). If I understand correctly, the inner panes should preserve their horizontal scrollbar during browser window resize, and also when the panes are resized using the Splitter resizer. Please correct me if I am wrong.

The containers scrollbars in the demo are persisted, when the browser window is changed and when the splitter resizer is used. However, when the width of the pane satisfies the container, the horizontal scrollbar is removed, but I cannot see such a thing being added to the browser. For convenience, I attached a screen recording of the Splitter and its panes.

Please check the demo and the video and let me know what I am missing. Thank you.

As for the height and scrollbars of the panes, the developer needs to ensure that when using height 100% of an element, there is a parent with a fixed height (so that 1--% can be calculated from something), or set height 100% up to the body.

Here is an example. where each pane receives its own vertical scrollbar when the browser is resized:

https://stackblitz.com/edit/angular-w4pkzb-smuqle

I am looking forward to your reply.

Regards,
Martin Bechev
Progress Telerik

[Michael]

Hi Martin,

thank you for looking into this!

For the first part: the strange behavior can be reproduced with the stackblitz you prepared.
Steps would be:
1. Open the stackblitz app in a separate tab
2. resize the browser window -> everthing is as expected
3. change the splitter pane ratio by dragging the splitter bar
4. resize the browser window again; now, the splitter panes do not properly adapt anymore.

Another, even worse problem is the following scenario:
1. Open stackblitz app
2. <resize the browser window e.g. to half the screen width)
3. change the splitter pane ratio slightly by dragging the splitter bar
4. resize the browser window to full screen
-> now splitter panes do not resize to full screen any longer

I attach two screen recordings (in webm format, hope this is fine for you). It is recorded on chrome / linux, but the behavior is according on windows / firefox / edge.

Thank you again
Regards
Michael

[Michael]

And thank you for the proposed solution to my second question, which fits exactly! 
(besides, I should have known this :-| ) 

Regards
Michael