DockManager&Tabs Issues

[Bohdan]

Hi Telerik Team,

While working with the DockManager component we encountered a few issues / potential improvements:

1. Inconsistent pane header height
   - When pane are in different visual states (headers displayed as a Tab vs. as a PaneHeader), their heights differ.  
   - Feature request: please consider introducing size enums (e.g. Small / Medium / Large) so that developers can adjust the header size. At the very least, making the heights consistent by default would help.

2. Last tab not transforming back to PaneHeader
   - When multiple panes are attached to the same field, they stack as tabs in a TabStrip.  
   - However, when only one pane remains(after any drag and drop to another field), it still stays inside the TabStrip instead of transforming back to the PaneHeader UI.  
   - Why is this the case? From a UX perspective, it would be more natural for the last tab to revert to the pane header style.

3. Conflicting CSS classes applied
   - When a pane is defined as follows:

<DockManagerContentPane HeaderText="@AppService.CurrentPageTitle"
                             AllowFloat="false"
                             Unpinnable="false"
                             Closeable="false"
                             Dockable="false">

   - The content area receives both k-pane-content AND k-tabstrip-content classes.  
   - This results in broken UI: double scrollbars, extra padding, and layout inconsistencies.

Screenshots attached for reference.
If something is not clear, feel free to ask, I would try to explain better =)

Thanks,
Regards,
Bohdan

[Ivan Danchev]

Hi Bohdan,

With regard to point 1. in both cases the panes inherit different styles, due to the difference in rendering and the classes applied to the respective elements. With that said, requesting the height to be the same within the context of the DockManager makes sense, so consider logging this as a feature request in our Feedback Portal: https://feedback.telerik.com/blazor 

Even without a dedicated implementation, you can customize the pane's appearance and achieve the same height (and font-size) through custom CSS: 

<style>
    .k-pane-title {
        font-size: 0.875rem !important;
    }

    .k-pane-header {
        height: 33.8px !important;
    }
</style>

Here's a runnable example: https://blazorrepl.telerik.com/cfOsmtve12dDa3Gz20 

2. As for the transformation mentioned in 2., whether this is more natural or not is subjective, but you may log a separate feature request, which would allow us to gauge the community's sentiment for such a change in the behavior. 

3. The k-tabstrip-content class is applied to the container element within the tab that wraps the pane's content. It is part of the rendering of the TabStrip. I've tested it in this REPL example: https://blazorrepl.telerik.com/mJuMQDFI27jum0W112  with the Tab 2.1 pane: 

<DockManagerContentPane HeaderText="Tab 2.1"
                AllowFloat="false"
                Unpinnable="false"
                Closeable="false"
                Dockable="false">
    <Content>
        First Tab Content
    </Content>
</DockManagerContentPane>

which renders as a tab due to being nested in a DockManagerTabGroupPane. I see no issues in the way it appears. Could you please modify the example accordingly and demonstrate what the problem is? 

Regards,
Ivan Danchev
Progress Telerik

[Bohdan]

Hi, Ivan Danchev,

1. The suggested CSS workaround does not survive theme switch.
3. I couldn't reproduce the issue in that sample, so I decided to move further, and found a problem.

I simply added 

<link rel="stylesheet" href="bootstrap/bootstrap.min.css" />

 line in App.razor after Telerik css:

 

<link rel="stylesheet" href="_content/Telerik.UI.for.Blazor/css/kendo-theme-default/all.css" />

another solution without bootstrap line is next:

<style>
    *, *::before, *::after {
        box-sizing: border-box;
    }
</style>

So, here are the questions:
1. Is it really necessary to add this line or the problem lies somewhere deeper? We don't want to use Bootstrap, we want clean Telerik styles. Is it a bug or a limitation?

2. If including the Bootstrap CSS is required, why isn’t it added by the Telerik VS project template?
Regardless of whether it’s required or not, this should be clearly documented in Getting Started - with guidance on when and why to use it - so developers don’t run into unexpected layout issues.

attaching demo-gif to better show the issue.


Regards,
Bohdan

[Dimo]

Hi Bohdan,

>> The suggested CSS workaround does not survive theme switch.

This shouldn't happen. Please check if the <style> tag still exists on the web page after a theme switch. If yes, then check the DOM inspector what other styles prevail. If not, then debug the theme switching logic and see what removes the <style> tag.

>> Bootstrap styles

Bootstrap styles or border-box sizing are not required by our components. I see what you mean by "double padding" and I am not sure this is indeed expected. I will ask about this. In the meantime, you can remove the double padding with:

    .k-dock-manager-splitter .k-tabstrip-content > .k-pane-content {
        padding: 0;
    }

[Bohdan]

Hi Dimo,

I have updated my VS extension, created fully new project of 11.1.0 version, and now even adding bootstrap css line in App.razor doesn't help. Unwanted scrollbar still appears.

Previously I was using Extension version from 2024, don't remember which exactly...

Appreciate your help,
Regards,
Bohdan

[Dimo]

@Bohdan - it looks like your scenario may be different than what we have demonstrated as a solution in our examples. So, please send us an isolated runnable demo, which exhibits the discussed problem, so that we can verify if we are talking about the same thing.

[Bohdan]

@Dimo -
Sending zip with runnable example.

Scrollbar appears in main body tab-pane.

Bohdan

[Dimo]

@Bohdan

The app is missing the workaround I suggested earlier. Please add it to app.css.

    .k-dock-manager-splitter .k-tabstrip-content > .k-pane-content {
        padding: 0;
    }

[Bohdan]

Thank you for the response.

I would like to clarify my intention behind opening this forum post: when I used such basic component for basic use-case, I did not expect to encounter these kinds of layout problems. That is why I took the time to explain the issue in detail and to provide my research and findings — in order to help improve the components themselves and to prevent new developers from running into the same situation.

Of course, I am aware that a CSS workaround can resolve the visual symptom, but that was not the main point of my report. My goal was to highlight a scenario where the built-in behavior should ideally “just work” out of the box, without additional overrides.

I kindly ask you to consider whether this could be addressed in the component implementation itself, rather than only relying on external CSS adjustments. That would make the framework more robust and improve the developer experience overall.
Because at the moment, it feels as if the developer has simply “done something wrong” and is forced to spend time researching and applying custom fixes, while in reality the issue originates in the component itself.

Thanks,
Regards,
Bohdan

[Dimo]

Sure, I already contacted our front-end team about the potentially incorrect HTML output, and we will fix it.

[Bohdan]

Cool, thanks!