A "sectioned" render mode for grouped rows

[julien-f]

Grouping always renders as header rows inside one continuous <table> — there's no way to render each top-level group as its own visually separate, independently bordered/margined block, since a <tr> can't carry its own box-shadow/margin.

Add an opt-in render mode (one <table> — or equivalent — per top-level group, sharing the same column/view-state model) for consumers who need groups to read as distinct sections rather than a continuous scroll.

Needed for: layouts where visual separation between groups matters more than a single continuous, keyboard-navigable table surface.

[julien-f]

Looked into this. The blocker as stated (a <tr> can't carry its own box-shadow/margin) is right, but a full table-per-group split is more than the use case needs — pagination, keyboard nav, column drag-reorder, and the aggregate row all assume one continuous flattened row sequence across a single table (a group's rows can already split across a page boundary by design), so forking that per group means re-deriving most of it.

Lighter alternative that stays inside one <table>: split the <tbody> per top-level group (HTML allows multiple <tbody>s in one table) and add an opt-in groupBoxed that borders the first/last row of each group's <tbody> and inserts a small transparent spacer row between groups. This is a render-only decoration — no core changes, composes with pagination/selection/filtering for free, and collapse falls out automatically too: since collapse already removes row elements from the DOM (not display:none), a tr:first-child/tr:last-child border rule just re-resolves to hug whatever's left, no extra state to track. Prototype: https://claude.ai/code/artifact/1109b410-93c1-4056-8ed8-7425285b9231

That said, the implementation cost is still real once you count all four adapters (React/Vue/Solid + vanilla inheriting from Solid) needing the change plus tests across boxed × collapsed × paginated × filtered. Given there's no concrete consuming screen asking for this yet, we're not going to build it for now — revisit if/when an actual use case shows up.