feat: 3x3 frozen band model - right-frozen columns + simultaneous top/bottom frozen rows (ViewportMgr Phase 4)

[6pac]

Summary

Completes the 3×3 band model. Rebased onto current master (includes the #1229 squash and the #1231/#1232 fixes — the scrollTo paging fix verified intact alongside the band code); supersedes the stacked #1236. Contains the full ViewportMgr series: the #1234 commits replay here identically, so #1234 can be closed in favour of this PR or merged first — either order works. SlickGrid now supports left AND right frozen columns and top AND bottom frozen rows in any combination — up to nine panes — all managed by ViewportMgr, with every legacy configuration byte-identical (proven by the phase 0–3 characterization suites, which run unchanged).

New capabilities (all opt-in via new options; defaults preserve current behaviour exactly)

• frozenRightColumn (count from the right edge — counts survive column reorder/hide, unlike index-based frozenColumn): a right-frozen column band with new *-right-frozen css classes. The historical "right" elements keep their names and become the scrollable middle band. Column-side selection, geometry (band pinned at the right edge, middle band shrinks), row-fragment routing (rowNode grows to 3 entries), band-local cell coordinates, keyboard navigation across the boundary, and Y-scroll following are all implemented and spec-pinned.
• frozenBottomRow (count, usable TOGETHER with frozenRow, which then always means top rows; the legacy frozenBottom flag keeps its exact historical single-band meaning): a bottom-frozen row band (*-bottom-frozen classes) with three-way row routing, geometry (band pinned below the body, above its scrollbar), X-scroll following, and runtime toggling. The shared bottom-frozen × right-frozen corner pane is created by whichever band materializes second.
• Public band API: getFrozenBandCounts() / getFrozenRightStartIndex(); cellrangeselector is migrated onto it, which also fixes its cross-canvas measurement under the new modes and adds correct offsets/clamps for the new bands.
• ViewportMgr extracted to slick.core.ts (registered on the Slick namespace beside DragExtendHandle; contracts in src/models/viewportMgr.interface.ts) — slick.grid.ts ends ~1,500 lines lighter than before the whole refactor, with zero frozen-flag branching outside setFrozenOptions. No consumer impact: core already loads before the grid everywhere.

Hardening

Three adversarial equivalence audits ran during Phase 4 (right-band transitions, bottom-band-off equivalence, init-window binding). Real defects found and fixed by them: stale-band routing/geometry guards after un-freezing, an init-window event double-binding (latent since the right-band milestone), and a dropped disableSelection on init-materialized headers. Known preserved quirks and invariants are documented in the source at their definitions.

Testing

Three new example pages and 25 new band tests across three specs (viewportmgr-right-frozen-band, viewportmgr-bottom-frozen-band, extended viewportmgr-lazy-materialization), covering init-time and runtime materialization, geometry, routing, navigation, and un-freeze restoration. Every commit in the series landed only after the full Cypress suite passed locally (632 tests). Headless-only retries: { runMode: 1 } added to the Cypress config after reproducing a ~1-in-4 machine-level flake on pristine master (three different victim specs across runs; CI here is the authoritative check).

🤖 Generated with Claude Code

[6pac]

Freeze activation options — ViewportMgr refactor (SlickGrid)

Reference for the grid-option surface controlling frozen rows/columns after the
ViewportMgr refactor (branches viewportmgr-phase1 / viewportmgr-phase4,
PRs #1234 / #1236). Companion docs: PLAN-panegrid.md, KNOWN-QUIRKS.md.

Option surface

Option	Kind	Default	Meaning
frozenColumn	legacy, index	-1	Left-frozen columns: freeze columns 0..N inclusive. Semantics unchanged from upstream.
frozenRow	legacy, count	-1	Frozen rows. Always the top band whenever frozenBottomRow is in use; otherwise positioned by frozenBottom.
frozenBottom	legacy flag	false	Positions the single frozenRow band at the bottom instead of the top. Ignored when frozenBottomRow > 0 (it only ever selects the single-band position).
frozenRightColumn	new, count from the right edge	0	Right-frozen column band. A count, not an index — counts stay correct when columns are reordered or hidden (avoids the index-drift problems calculateFrozenColumnIndexById patches for frozenColumn).
frozenBottomRow	new, count	0	Rows frozen at the bottom alongside top rows — the simultaneous top+bottom mode (three row bands).
lazyPanes	new, opt-in	false	Build only the top-left pane/viewport/canvas when nothing is frozen at construction; all other panes materialize on demand. Off by default because it changes the DOM for consumers that style/query the historically ever-present unused panes.

Activation model

• No allow-freeze presets. The originally planned init-time gates
  ("allow freeze left/right/top/bottom", which would have pre-created pane DOM and
  permanently fixed a grid's available freeze modes) were dropped during the
  dynamic-materialization feasibility work (plan §4b): band existence is driven
  directly by the freeze options themselves. Any freeze can be enabled or disabled
  at runtime via setOptions() on any grid; band DOM materializes on first use at
  its canonical position. The vestigial preCreateBands perf hint from the early
  API sketch was never needed and never implemented.
• A default-configured grid is byte-identical to the pre-refactor grid (all six
  classic panes built up front; freeze options show/hide and route).
• The two new bands (frozenRightColumn, frozenBottomRow) are always
  materialize-on-demand regardless of lazyPanes — set them in the constructor
  options or later via setOptions(); either path produces the same DOM.
• Un-freezing hides band panes but keeps them in the DOM (matches the historical
  always-present behaviour; see KNOWN-QUIRKS.md design decision Prevent useless onSelectedRangesChanged events in selectionmodels' setSelectedRanges #9).

Plugin-facing band API (for completeness)

• grid.getFrozenBandCounts() → { frozenLeftCols, frozenRightCols, frozenTopRows, frozenBottomRows } (a copy; zero = band absent)
• grid.getFrozenRightStartIndex() → index of the first right-frozen column, or the column count when the band is off (idx >= result is a safe membership test)

[6pac]

Will investigate ways to reduce the line count tomorrow, but this PR is the start for manual testing.

[ghiscoding]

What I'm worried about in this PR is the very large amount of new lines of code, over 1400 lines of code (loc) as shown below, that is a lot!!! The only thing that we're gaining here is right freeze and also to stop rendering panes that aren't being used (e.g. pane-right or pane-bottom, etc...). If so, 1400 loc for basically just adding right freeze, is just way too much. It would increase the lib size by a lot, we can certainly do better

[6pac]

looking into that, but I think it's worth testing at this point to sanity check the overall usability.

Claude is indicating that it kept a lot of architecture the same way just to maintain byte-identical HTML in thos PR, but we can lose about 600 further lines through a subsequent stage 2 refactor. I'm investigating adding the sticky rows feature as well - I'm interested to see if that would use a lot of the same code.

At the moment I'm not sreally sure how to roll this out though - this PR applies to main and can be merged locally without merging in the main repo, for testing. A further PR could I suppose also be pulled and merged locally on top of the previous merge. Is that workflow OK for you?

[ghiscoding]

I think that considering this is probably going to be released under a major (aka breaking) version, then there's no point in carrying over old code if you can rewrite it in a better way that might change certain flags and behaviours (that's what major versions are for). Like I said a while ago, we can create a branch named "next" or "dev" (based on master) and once accepted merge all your PRs on that next branch so that you can use it until ready to fully release it under a major version (that's what I've done in the past with v4 and v5), then merge back next into master when officially released.

The only PR that could be merged and released under current v5 is the variable row height, I would put more focus on finishing that one. Anything else (freeze/pinning rewrite, sticky columns, drop SortableJS, ...) should be done in a separate next or dev branch and consider that branch to be the future v6 (because all of these features contain some form of breaking changes/behaviors)

looking into that, but I think it's worth testing at this point to sanity check the overall usability.

I did test the UI quickly, that's how I saw that you did stop rendering the pane-right/pane-bottom/... when not displayed (which I agree with). But apart from the right column freeze (which seems a little off in the demo since left columns weren't covering all left space though it becomes ok when grid has lots of columns), that feature alone surely doesn't explain the addition of over 1400 loc

[6pac]

This PR has undergone three stages: 1) wrap the viewport/panes in an object, 2) rework individial viewport related objects (eg, ViewportL, ViewportR, HeaderL, HeaderR, HeaderRowL, HeaderRowR) into an array 3) encapsulate all multi pane concerns into the ViewportMgr object and take the slick.grid.ts code back to what it looked like before the frozen panes change.
This is the prompt for part 3, just to make clear what the motivation was.

---

The primary reason I wanted to do this change was to simplify the code in 'slick.grid.js'. This goal has not been met.

To illustrate what I mean, take the following examples:

SlickGrid-pre-frozen: (in createColumnHeaders())

  $headers.empty();
  $headers.width(getHeadersWidth());

SlickGrid-post-frozen: (in createColumnHeaders())

  $headerL.empty();
  $headerR.empty();

  getHeadersWidth();

  $headerL.width(headersWidthL);
  $headerR.width(headersWidthR);

6pac master: (in createColumnHeaders())

Utils.emptyElement(this._headerL);
Utils.emptyElement(this._headerR);

this.getHeadersWidth();

Utils.width(this._headerL, this.headersWidthL);
Utils.width(this._headerR, this.headersWidthR);

6pac viewportmgr-phase4: (in createColumnHeaders())

Utils.emptyElement(this._headerL);
if (this._headerR) {
  Utils.emptyElement(this._headerR);
}
if (this._viewportMgr.headerRF) {
  Utils.emptyElement(this._viewportMgr.headerRF);
}

this.getHeadersWidth();

Utils.width(this._headerL, this.headersWidthL);
Utils.width(this._headerR, this.headersWidthR);
Utils.width(this._viewportMgr.headerRF, this.headersWidthRF);

The pre-frozen code is simple and says exactly what it does. Then post-frozen, rather that reading the logical flow, you suddenly have to deal with multiple headers etc - and with the LazyPanes option we used the multiple headers may not even be actively used.
The current 6pac code more or less mirrors the post-frozen format, and viewportmgr-phase4 collapses some of the logic into the viewportmgr object, but it doesn't really change it.
What I'd like is for it to read something like:

desired:

  this._viewportMgr.headers.empty();
  this._viewportMgr.headers.width(getHeadersWidth());

This would require wrapping all of the headers and footers into the ViewportMgr object - and that's what I really wanted, a single object that slick.grid.js can manipulate like a single pane that keeps all of the concerns about how many pane/header/footer elements there are and hides them from the grid code.

Another example:

SlickGrid-pre-frozen:

function getFooterRowColumn(columnIdOrIdx) {
  var idx = (typeof columnIdOrIdx === "number" ? columnIdOrIdx : getColumnIndex(columnIdOrIdx));
  var $rtn = $footerRow.children().eq(idx);
  return $rtn && $rtn[0];
}

SlickGrid-post-frozen:

function getFooterRowColumn(columnIdOrIdx) {
  var idx = (typeof columnIdOrIdx === "number" ? columnIdOrIdx : getColumnIndex(columnIdOrIdx));

  var $footerRowTarget;

  if (hasFrozenColumns()) {
    if (idx <= options.frozenColumn) {
      $footerRowTarget = $footerRowL;
    } else {
      $footerRowTarget = $footerRowR;

      idx -= options.frozenColumn + 1;
    }
  } else {
    $footerRowTarget = $footerRowL;
  }

  var $footer = $footerRowTarget.children().eq(idx);
  return $footer && $footer[0];
}

6pac master:

/**
* Get the Footer Row Column DOM element by its column Id or index
* @param {Number|String} columnIdOrIdx - column Id or index
*/
getFooterRowColumn(columnIdOrIdx: number | string) {
  let idx = (typeof columnIdOrIdx === 'number' ? columnIdOrIdx : this.getColumnIndex(columnIdOrIdx));
  let footerRowTarget: HTMLDivElement;

  if (this.hasFrozenColumns()) {
    if (idx <= this._options.frozenColumn!) {
      footerRowTarget = this._footerRowL;
    } else {
      footerRowTarget = this._footerRowR;

      idx -= this._options.frozenColumn! + 1;
    }
  } else {
    footerRowTarget = this._footerRowL;
  }

  return footerRowTarget.children[idx] as HTMLDivElement;
}

6pac viewportmgr-phase4:

/** 
 * Get the Footer Row Column DOM element by its column Id or index
 * @param {Number|String} columnIdOrIdx - column Id or index
 */
getFooterRowColumn(columnIdOrIdx: number | string) {
  const idx = (typeof columnIdOrIdx === 'number' ? columnIdOrIdx : this.getColumnIndex(columnIdOrIdx));
  const footerRowTarget = this._viewportMgr.bandElementForColumn(idx, this._footerRowL, this._footerRowR,  this._viewportMgr.footerRowRF);

 return footerRowTarget.children[this._viewportMgr.bandLocalColumnIdx(idx)] as HTMLDivElement;

}

desired:

/**
 * Get the Footer Row Column DOM element by its column Id or index
 * @param {Number|String} columnIdOrIdx - column Id or index
 */
getFooterRowColumn(columnIdOrIdx: number | string) {
  const idx = (typeof columnIdOrIdx === 'number' ? columnIdOrIdx : this.getColumnIndex(columnIdOrIdx));
  return this._viewportMgr.getColumnChildren(idx);
}

Report on the feasibility of this, and list the proposed new members of ViewportMgr, and before and after code in slick.grid.ts for each use case in that file. It impacts on both the viewportmgr-phase4 and the m16 plan currently in progress.
Also assess if it would be easier to start from scratch and redo the whole viewportmgr-phase4 PR, or to update and replace the m18 work, or to add it on after m18?

[ghiscoding]

@6pac so I asked Codex 5.6 Sol (which is the equivalent to Claude Fable 5) to see if I can replicate this PR but to do it in a target of 300-400 LOC (line of code) and it was able to achieve that (instead of 1400 loc which is what you have so far), but...

then I had another idea, what if we implement the same approach as Ag-Grid (column pinning) and/or SyncFusion grid (frozen row/column)? The biggest advantage is that the UI is much more appealing since it only has 1 horizontal scroll and 1 vertical scroll for the entire grid even if it's 3x3 or more, so the UI is much more user friendly I find (versus SlickGrid freezing which has multiple scrollbars with most of them disable but visible for alignments)

So I asked Codex to try to implement the same concept as Ag-Grid, it called that a Docking Controller, this is still a POC but after an evening on it, I have a rough working POC. I like this approach much better and the bonus is that I asked Codex to eventually add sticky in combo with pinning and it would totally be doable without that much more loc addition.

Screencast_20260903_005128-2.webm

I asked the AI to give me an LOC estimate after what I have working so far including the addition of pinning and sticky, the result is shown below (please note that the LOC count includes CSS stylesheet lines)

Scope	Rough LOC
Permanent pinning implementation retained after cleanup	~1,100–1,400 gross LOC
Basic sticky columns/rows added on top	+150–300 LOC
Grouped quarterly sticky headers added on top	+150–300 additional LOC

so in the end, I'm much more interested in this new approach of a Docking Controller with single scrollbar instead of your Viewport Manager (this PR). I've burned almost all my weekly tokens for reasoning and implementing this, so I might only finish it next week, but it's looking good so far... what do you think? Also again a reminder that this would only be released in our next major version because there's obviously some breaking changes on the entire DOM and also the grid options changes and all.

Also compared to Ag-Grid, my POC keeps pinning as column index (pin all columns up to x), but Ag-Grid actually separates each column pinning, meaning that you pin each column independently (you could pin column 1 and 3, but leave 2 unpin which would move it to the right pane since it isn't pinned). I'm not sure if we should use this approach or keep using "pin up to x" approach, Ag-Grid is more flexible but it requires adding { pinned: "left"} for each column being pinned instead of us just using an index, which is better is debatable I guess but we could do probably do both.

cc @zewa666

[zewa666]

jeez this looks mighty as hell. lots of tasks on my table but I definitely need to check this out soon

[6pac]

Interesting! What you are proposing sounds better than the SlickGrid frozen columns feature presently, and the sticky grids feature would be awesome.

But go up a few comments and read where I say 'This is the prompt for part 3, just to make clear what the motivation was.' I don't think it fulfils that requirement at all.

So I have to rethink how important that is to me. TBH, it was quite important when I thought I would be hand-coding going forwards, but now that AI is doing all the work, it probably doesn't matter if the codebase is hard to read. And honestly, I think we're nearly there re the feature set. How much more can we implement?

I am quite keen at this point to do the next breaking release with what we have and just clean the slate. Then I think we're well-positioned to run these kind of experiments with much less rebase churn.

[ghiscoding]

@6pac I understand your concern but this new concept (which again is follow Ag-Grid approach) is totally different compare to the previous div containers (I see them as independent silos on a farm) but with the new approach it's rather working with divs and rows, it's very different in the DOM (which is totally a breaking change especially for E2E tests, I'm assuming this would break a lot of the Cypress tests and will require lots of refactoring). At this point, I'm only focusing on making it work, I haven't looked that much at the code but your comment above is part of the AI completion task.

I think it's also a good time to get rid of that +/- 1000px offset that I never understood what it does exactly. It might have been an IE fix of some kind, it's time to get rid of these old hacks I think

Anyway, I asked the AI to compare current POC with your point 3 above (I literraly provided your entire comment above) and it replied with:

Codex analysis of your previous comment

The original PR’s principle is exactly right—and the current POC has not reached that maintainable end state yet.

The architectural direction is better: one viewport, one canvas, one horizontal scrollbar, and a pure DockingController for pin/sticky policy. But the current implementation is temporarily harder to read because the old multi-pane model still exists alongside it.

Area	Current POC	Required final state
DOM setup	Creates four panes/canvases, then removes three in activateSingleViewportLayout()	Construct only one viewport/canvas/header/header-row/footer from the start
Headers/footers	Still empties and sizes L and R, and branches on frozen state in createColumnHeaders()	One header container; pinning only changes each cell’s docking class/position
DOM getters	getHeaderColumn, getHeaderRowColumn, and getFooterRowColumn still dispatch between frozen panes	Direct lookup from the one chrome container, by column index/id
Resize/scroll	Large dormant frozen-row/frozen-column branches remain	One resize and scroll path, with docking offsets as the only special behavior

The clearest warning sign is [`setFrozenOptions()`](/home/ghislainb/sourcecode/slickgrid-universal/packages/common/src/core/slickGrid.ts): it force-disables the old API, but all of the fields and branches it protects are still present. That is useful for a POC, but it should never be the final form. There are still hundreds of freeze/pane-related references in packages/common.

I would not revive the old ViewportMgr approach. Its purpose was to hide a genuinely multi-pane renderer; this rewrite should delete that renderer. A manager would only conceal legacy complexity rather than remove it.

The desired final code should look close to the pre-frozen examples from the PR:

this._header.replaceChildren();
this._header.style.width = `${this.getHeadersWidth()}px`;
return this._footerRow.children[columnIndex] as HTMLDivElement;

Pinning-specific logic should be confined to:

• DockingController: calculates left/center/right and top/center/bottom membership.
• A small docking DOM layer: applies region offsets/classes and handles per-row left/center/right placement.
• The virtual renderer: renders one row node and its three optional regions.

Everything else should no longer know “left pane”, “right pane”, “top pane”, or “frozen”.

Because this is intentionally breaking, I recommend making this a merge/acceptance condition: no dormant hasFrozenColumns()/hasFrozenRows branches in normal rendering, no _headerL/_headerR or _viewportTopL/_viewportTopR model, and no compatibility disabling like setFrozenOptions(). Rename the surviving singular elements to _header, _headerRow, _footerRow, _viewport, and _canvas.

So: the POC is a good substrate, but merging it before the deletion/consolidation pass would make maintenance worse. The cleanup pass is not optional polish; it is the part that realizes the original PR’s simplification goal.

updated DOM

below you can see that we're dealing more with rows instead of previously entire div container silo, we have 3 possible div container for each row, we have a slick-pinned-left-cells, then slick-scrolling-cells and also slick-pinned-right-cells, if you want to add more, then it's a lot more flexible and possible. Also I think this approach is what makes it easy to add sticky columns/rows.

[ghiscoding]

@6pac @zewa666 there you go, another 200-300 loc maybe and we have sticky columns and rows (in addition to pinning feature). I have 2 separate examples, 1 example for pinning and 1 example for sticky. They are 2 separate features but they share a lot of code together. Can we use both pinning and sticky in the same example? I'm not sure maybe... but I would think that the basic idea is to use pinning or sticky separately.

after having both pinning and features, I asked the AI to give me another LOC count update:

The +1,656 additions / +1,469 net LOC covers the combined POC implementation for:

• Single-viewport pinning
• Sticky columns and rows
• Shared docking resolver
• Public API/interface changes
• Required shared SCSS styling

It does not include Example 04, Example 47, tests, or framework demos. It also still includes legacy frozen-pane code that is planned for removal, so the final cleaned net LOC should be lower.

Screencast_20260903_184235.webm

isn't that awesome? Also note that I did not do a code cleanup or review yet, I mean I'm focused on making the POC work. There's most probably lot of cleanup that we could do to decrease LOC count and drop any legacy frozen related stuff (because again this is definitely a breaking change and totally different UI/UX)... and now I'm really close to be out of tokens (less 8% left), so I will probably have to pause for couple days.

[6pac]

OK, it sounds like this will also meet my goal. The only issue is the change for those who might be wedded to the way the frozen rows/column feature works already.
As I've said - that's not me, I've never once used the frozen rows feature.

So I'm 100% happy with this, but I think it's probably worth asking some consumers of the frozen feature what they think.

[6pac]

Great work by the way, this is exactly what the project needs - new ways of looking at problems!

[ghiscoding]

@6pac That's what breaking version (major) really mean and that is also why I want this renamed to pinning rather than freezing. Also nowadays, AI will do most of the work anyway. I mean you could ask @zewa666 but he's probably going to answer the same as me... Ideally, just a global search & replace should do the work but it might depend on the answer for the question below.

What I'm unsure at this point though is as I mentioned above, should we use pinning on

1. each individual column (that's what Ag-Grid does via { pinned: 'left' } on an individual basis).
   • you could also pin column 1 and 3 but skip column 2 and that would move column 2 to the right (unpin section)
2. keep only pinning index in the grid options (same as frozen column but with a different option name).
3. support both via 1 and 3, via column definition and/or grid option.

The sticky part is done on the column basis, so perhaps we should do the same for pinning?

[6pac]

Sure, don't take this as a criticism. I think this is a good change.

What I'm saying is that a major version usually means 'we've had to break some things to move forward and you'll need to check your code'.
Removing and replacing a major feature is a little more than that. Just not sure of the reaction we'll get. The scenario I'm thinking of (which seems common at the moment) is consumers with Excel-like spreadsheet grids, where they have their users trained to a particular mode of operation. Often, training issues are just as thorny as functional ones.

[6pac]

Re the config, I'd tend to favour 1) but again be good to get opinions from people who want to use it, ie. try to think of a use case that will break it.

[ghiscoding]

no worries, I did take it as a constructive comment. So on the breaking change side of things, I do typically like to offer some kind of transitions... but in this case I don't see any possible way of doing it because I certainly don't want to support both legacy freezing and this new pinning.

For the implementation choice, I had another thought and I think that going with an hybrid approach is the best possible way to avoid this from being an even bigger breaking change. Let me explain, in Slickgrid-Universal, we also have Grid State & Preset and I did add the freezing columns in there and we do use it on a big project at work. So if we move it to the column instead of the grid option, that would a much bigger breaking change and an hybrid approach (with grid option index) would smoothen the blow I think.

For a survey, we could open one in the Discussion tab, but the problem is that barely anyone would see it, the only other option would be to tag people directly, typically the big users and/or recent contributors. I did that couple times. But I think I need to go further with the POC before doing any such survey. Like I said earlier, I didn't even look much at the code, neither the grid options, and so I need to advance the POC more into an MVP before making any surveying. I'm pretty sure that most user would simply be happy with the breaking change especially considering the better UI/UX... I also have to make sure that we're not decreasing in perf for very large dataset with this new pinning/sticky approach. Once I'm done, I would ask you to make a second view analysis with Claude, having 2 reviews from 2 different AI is even better

[zewa666]

I think the major version would indicate this well enough. yeah its a bit more than a break, its a feature deprecation sort of, but the replacement is subjectively better for me.

what the latest push in AI development made me think of though is that we might should start thinking about shipping curated skills along with the library. that would serve two purposes. first, LLMs would know better how to apply specific features from slickgrid on the consumer end. but secondly, the skills could also act as a verification of the docs and thus overall improve the development of new features as LLMs could check up on skills when touching existing features

[6pac]

@zewa666 I agree there should be something along those lines. A comprehensive reference manual, would be a good start.
I'm working on that in the background, but I'm currently doing another manual for another project, so I was leaving this until afterwards to apply lessons learned.

[6pac]

@ghiscoding I've had a bit of time to think about this now.

As I said, personally I have no preference around these; I'm fine with what you've proposed above.

But I wonder, there do seem to be a lot of developers using SlickGrid essentially as an Excel replacement. I think this new proposal is different to how Excel behaves? So I do wonder if that will be a problem for them.

Also, is it possible for me to get access to the PR/code branch for this? Or has it been done on SlickGrid-Universal?

It seems a bit crazy, but now I'm wondering if we should offer all three options - the classic frozen rows/columns, the viewport-based frozen rows/columns and the sticky columns. It would definitely increase the codebase size (and complexity) significantly, but a lot of the more complex logic could be spun off to plugins.

I know at least one organisation that's using this for an Excel-like purpose, so I've contacted them and sent some links for comment.

[ghiscoding]

@6pac I'm still working on it in Slickgrid-Universal only via PR ghiscoding/slickgrid-universal#2782, once I'm done then I'll ask Codex to replicate the entire thing in here. Should we keep the freezing option, the answer is No... but we can replicate similar behaviour to what freezing was.

So let me explain, the new feature is being renamed to Pinning (the freezing wording is being dropped) because I wanted to start with new naming since it's a full rewrite, but also because it's really different single it's just single column Pinning (it adds pinnable and pinned to column definition, pinned). The freezing definition in current SlickGrid is defined as "freeze from column 0 to X", but with the new implementation, it's a single column Pinning (1 at a time via pinned and not an up to X anymore) and that is a big distinction because it now allows us to Pin at different indexing positions (e.g. if we have Column 1, 2, 3, ... we could Pin 1, 3 and skip 2 and that is now possible). Does that mean the end user will have to Pin 1-by-1? Yes and No, I added a internal function that basically loops through from 0 to X and toggles every column pinned flag.

The other great thing that I love with the new UI is that we now have what it calls Docking and we no longer have separate divs with separate scrollbars, we now 1 horizontal scrollbar and 1 vertical scrollbar with/without Pinning. My main reference was Ag-Grid, Codex implemented the same approach, which I like a lot (single scrollbar is so much nicer and usable)

in the print screen below, we can now have all Pinning sides all at once without any issues

It now works correctly with Grouping as well, this will fix the super old issue #443, you can also see below that I pinned the 2nd column which keeps the checkboxes (1st column) to the unpin section, single column pinning is just so much more flexible than before

Screencast_20260910_223012-1.webm

I'll probably be done by early next week and replicate the PR in here. It did a lot of rewrite, lot of variable changes (there's no pane, nor freezing container anymore) and re-implemented pretty much the entire way of showing things. Also as part of my acceptance, I did provide your original goal feedback (making it more readable) to my goals list, so it is being considered.

I do keep a progress file for the AI to stay focus, you can see the current Pinning Progress

Also since I have full unit test suite, codecov currently reports ~750 LOC (that's raw LOC, without comments and without any CSS) and that does include Sticky feature as well. So I'm very satisfied with the end result, this fixes a lot of UX problems I've encountered over the years.

[6pac]

Great, thanks for providing the progress update.

[ghiscoding]

and I've just fixed the last bug I found, it now works with colspan and pinning too (though it required ~75 LOC to fix), with the small exception that the pinning must be sequential (e.g. works with pinned: [0, 1] but doesn't work unsequential like [0, 2] when some are skipped). So the colspan below looks like it's cell that spans across the pinning boundary, but in reality, it's just an illusion and is really 2 cells that look like 1 large cell and so we just fool the end user for a better UX 😆

Screencast_20260911_013813.webm

also I forgot to provide some code sample to explain what I meant above

gridOptions = {
- frozenColumn: 2,
- frozenRow: 2,
- frozenBottom: false,
+ pinning: { 
+   columns: { 
+     left: 2, // pin from 0 to 2.. or use `[0, 1, 2]` which is equivalent
+      // you can "right" too
+    },
+   rows: {
+     top: [0, 1], // or integer from 0 to X
+     // you can add "bottom" too
+   }
}

or you could just simply define it directly in the column definition via pinned and if you want to block a column then use pinnable: false

columns = [{
  id: 'firstName',
  field: 'firstName',
+ pinned: true,
}, {
  id: 'lastName',
  field: 'lastName',
+ pinnabled: false, // cannot be pinned dynamically
}]

what about the Sticky feature? That one is via column definition for the sticky columns, and via grid options for the sticky rows

gridOptions = {
+ stickyRows: { 
+   both: ['total-revenue', 'total-expenses', 'net-profit'] 
+ },
}

sticky columns

columns = [{
  id: 'firstName',
  field: 'firstName',
+ sticky: 'both', // can be "left", "right" or "both" for which side to stick
}]

that's it, pretty straightforward I think... oh 1 very important thing I forgot to mention the +/- 1000px offset is gone, I assume that was in place for issues with IE6 but we no longer need this and it was causing issues at first, so yeah it's gone!

[6pac]

Closed- superseded by new single-pane approach.