Support header height auto-sizing

[muendlein]

Clear and concise description of the problem

I want the header row to size itself to whatever content is actually rendered in .slick-header-column (multi-line HTML titles or DOM titles) so that column titles aren't silently clipped whenever they need more than one line.

Suggested solution

Add an opt-in grid option, e.g. autoHeaderHeight.

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Wikis.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[6pac-ai]

Thanks for the request. autoHeaderHeight is a good name — let's go with that.

I've prototyped this in the browser to size up the work. Short version: most of it is cheap, the non-frozen case is nearly free, and frozen grids are where the real work sits.

Why most of it is cheap

Three things already work in our favour:

1. getViewportHeight() measures the header from the DOM — Utils.toFloat(Utils.height(this._headerScroller[0])). Nothing hard-codes header height in JS, so the viewport and canvas math already adapts to whatever height the header actually has. No new layout arithmetic is needed.
2. Header columns are in normal flow (float: left; display: inline-block; position: relative), so lifting the fixed height lets .slick-header-columns grow on its own.
3. .slick-header-column already has white-space: pre-wrap — the text already wraps. It is only clipped by height + overflow: hidden.

Today the only mechanism is manual and alpine-only: --alpine-header-name-row-count: 2 doubles a fixed height. If you set 2 and a title needs 3 lines, it clips — which is exactly the problem being reported.

Prototype results

Applying height: auto to the header columns, relaxing the inner column name's ellipsis, then calling resizeCanvas():

	container	header	viewport	overflows container	header panes L/R
Non-frozen, baseline	500	32	466	no	—
Non-frozen, auto	500	170	328	no	—
Frozen (frozenColumn: 2, frozenRow: 5), auto	350	216	107	yes, +183px	216 vs 193

So the non-frozen path works with CSS alone — the viewport shrinks correctly and nothing clips. On the frozen path the grid overflows its container by 183px (stable across repeated resizeCanvas() calls, so it is a genuine gap rather than a settling problem), and the two header panes size independently — 216 vs 193, exactly one line apart.

Suggested plan

1. CSS, behind an opt-in class. A slick-header-auto-height class on the header containers setting height: auto with min-height at the current value, and relaxing overflow/text-overflow on .slick-column-name. This has to override two places — the theme's --alpine-header-column-height and the base .slick-header-column.ui-state-default { height: 16px } in slick.grid.scss — so it stays theme-agnostic.

2. Option and wiring. autoHeaderHeight?: boolean (default false) in GridOption and _defaults, applied from createColumnHeaders(), with a resizeCanvas() once the headers are in the DOM. Non-frozen grids are complete at this point.

3. Frozen panes. Equalise _headerL / _headerR to the taller of the two after measuring, and subtract the enlarged header from paneTopH / viewportTopH so the grid stops overflowing its container. This is the only genuinely new layout code.

4. Re-measure triggers. Wrapping changes whenever a column's width changes, so the height must be recomputed after applyColumnHeaderWidths(), on onColumnsResized, and on container resize. Worth noting: applyColumnHeaderWidths() is called continuously during a resize drag, so recomputing on every mousemove will be janky — better to recompute on drag end. This also needs an only-if-changed guard and an iteration cap, because taller header → shorter viewport → possible scrollbar → different width → different wrapping is a real feedback loop.

5. Example and test. An example-auto-header-height.html with wrapping titles plus a frozen variant, and a Cypress spec asserting that no header column is clipped (scrollHeight <= clientHeight), that the two frozen header panes match, and that the grid does not exceed its container. That last assertion is what catches the step 3 problem.

6. Wiki/docs entry.

One open question

Steps 1–2 are small and solve the reported case. Step 3 is a meaningful chunk. Shipping 1–2 first with frozen grids unsupported would be a reasonable increment — but in that case the option should warn or be rejected for frozen grids rather than silently producing a grid that overflows its container.

@muendlein — does your use case involve frozen columns or rows? That determines whether the first increment would be enough for you.

[jahanbakhsh18]

This issue addresses a long-standing requirement, particularly for cases where header content is wider than the data columns. Based on the suggested plan from @6pac-ai, I have made progress on the implementation:

Steps 1 & 2 - Completed:
- Added a CSS class slick-header-auto-height and autoHeaderHeight grid option
- The solution works with minimal effort for non-frozen grids

Here's the minimal CSS that addresses the issue without any code changes (for demonstration purposes):

.slick-header-column {
    height: auto;
    overflow: visible;
}
.slick-header-column .slick-column-name {
    white-space: pre-wrap;
    overflow: visible;
    text-overflow: clip;
}

Step 3 - Feasibility Confirmed:
I've analyzed the frozen panes issue. The root cause is that left and right header panes size independently, so we need to:
- Equalize both panes to the taller height
- Adjust paneTopH and viewportTopH to prevent container overflow
The solution is feasible and I have a clear implementation plan.

Before I continue further, I wanted to check if you're already working on this issue or planning to (@muendlein). This will help us avoid duplicate efforts. Otherwise, I would be happy to continue working on this issue and complete the remaining steps.

Please let me know your status, and if you're not actively working on it, I'd appreciate being assigned to this issue.

[muendlein]

@jahanbakhsh18 I'm neither planned nor started working on this issue. Please note however that for DOM and text a different behavior might be intended as text can wrap while DOM can't. Forcing a text header into multiple rows should not be the default behavior.

[jahanbakhsh18]

@muendlein Thank you very much for your quick reply and for the important point you raised. I completely understand your hint. You are right that this should not be the default behavior. My plan is exactly as you suggested: this must be an optional feature. The user should turn it on only when they need it, using a clear grid option like autoHeaderHeight: true. The default will stay false, so the grid will work exactly as it always has.

@6pac I noticed that you recently merged a big feature for variable row height (PR #1235). That feature added a lot of the internal "plumbing" needed to handle dynamic heights. Does this autoHeaderHeight issue fit well with that new system? Or would it be a separate piece of work?

@6pac and @ghiscoding: If you agree it is useful, do you have any suggestions on how the implementation should be planned, especially considering the recent variable height changes? I am happy to adjust the plan based on your feedback.

I am looking forward to your thoughts. Thanks again to everyone for the discussion so far...

[ghiscoding]

Does this autoHeaderHeight issue fit well with that new system? Or would it be a separate piece of work?

That's a totally separate piece and Variable Row Height also has its own grid option flag as well (mostly for perf reasons).

What the AI above wrote seems fair enough and if you provide that to another AI then it should implement it pretty easily. I also don't want this as the default (some titles can be extremely long), so the autoHeaderHeight seems like a good fit.