feat(table): add support for tfoot#8034
Conversation
WalkthroughIntroduces new public flags (IsPlain, HasStickyHeader, HasStickyFooter) for table component configuration, replacing modifier-based approaches. Adds sticky footer support with new CSS variables and styling. Introduces new table-tfoot.hbs template for table footer rendering. Updates examples and documentation accordingly. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Pre-merge checks✅ Passed checks (3 passed)
Comment |
|
Preview: https://pf-pr-8034.surge.sh A11y report: https://pf-pr-8034-a11y.surge.sh |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
src/patternfly/components/Table/table.scss (1)
257-263: Sticky header/footer and tfoot styling look consistent; consider documenting.pf-m-sticky-footeralongside header
- The new sticky footer vars and block mirror the sticky header pattern and look correct:
position: sticky+inset-block-end: 0, separate z-index vars, and a border pseudo-element to avoid double borders with the last tbody row.- The switch to
inset: 0for the sticky header border pseudo-element is a nice cleanup and should be behavior‑preserving.- The
.pf-v6-c-table__tfootblock wiring (--table__tr--BorderBlockEndWidth: 0,vertical-align: top) matches the newtable-tfoot.hbsusage.One small follow-up suggestion: in the “Sticky table usage” docs table you still only list
.pf-m-sticky-header. It would be clearer to add.pf-m-sticky-footerthere as well, now that the modifier exists and is wired totable--HasStickyFooter.Also applies to: 285-288, 328-349, 1303-1308
src/patternfly/components/Table/examples/Table.md (3)
3762-3927: Sticky header examples correctly migrated totable--HasStickyHeader; consider minor doc tweak
- The main sticky header example (
table-sticky-header) and the nested-column sticky header example both now usetable--HasStickyHeader=true, which matches the template wiring and SCSS.- Extra body rows added to the sticky header example are just demo content and properly use
table-td--data-labelas before.Optional doc improvement: in the “Sticky table usage” table you still only list
.pf-m-sticky-headeras a class. You might want to mention thetable--HasStickyHeaderflag there as the preferred way to enable it in examples, mirroring what you did for the plain variant.Also applies to: 4371-4415
3933-4112: Sticky footer demo looks sound; document the modifier/flag more explicitlyThe new “Sticky footer” example:
- Uses
table--HasStickyFooter=trueand atable-tfootblock, which is exactly what the new SCSS andtable-tfoot.hbsexpect.- Uses
<th scope="row">in the footer row, which is good for accessibility.- Has enough body rows to actually demonstrate the sticky behavior in the scrollable preview.
I’d suggest extending the “Sticky table usage” or “Table footer usage” docs to explicitly mention both
.pf-m-sticky-footerand thetable--HasStickyFooterflag, similar to how sticky headers and the plain variant are documented, so consumers know both the underlying class and the preferred flag.
5328-5445: Table footer examples and usage are consistent; fix the earlier ‘Applied to’ type to match
- The new “Table footer” example uses
table-tfootwith a single summary row and<th scope="row">, which is semantically correct.- The usage table documents
.pf-v6-c-table__tfootapplied totfoot, matching the newtable-tfoot.hbstemplate and SCSS.One follow-up: in the earlier “Basic table usage” table,
.pf-v6-c-table__thead,.pf-v6-c-table__tbody, and.pf-v6-c-table__tfootare documented as applied to<tr>, but the implementation (and these examples) apply them to<thead>,<tbody>, and<tfoot>. It would be good to update that “Applied to” column for consistency.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/patternfly/components/Table/examples/Table.css(1 hunks)src/patternfly/components/Table/examples/Table.md(6 hunks)src/patternfly/components/Table/table-tfoot.hbs(1 hunks)src/patternfly/components/Table/table.hbs(1 hunks)src/patternfly/components/Table/table.scss(6 hunks)src/patternfly/demos/Table/examples/Table.md(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build-upload
🔇 Additional comments (6)
src/patternfly/components/Table/table.scss (1)
526-529: Action cell padding variables updated correctly to table-scoped tokensThe padding overrides for
.pf-v6-c-table__td.pf-m-action(both default and compact) now use the public--pf-v6-c-table--cell--*variables instead of the older internal names, which aligns with the token strategy used in the root of this file. I don’t see any behavioral regressions here.Also applies to: 1217-1219
src/patternfly/components/Table/examples/Table.css (1)
14-15: Preview height extension to sticky footer demo is appropriateExtending the
height: 400pxrule to#ws-core-c-table-sticky-footer .ws-preview-htmlmatches the sticky header preview behavior and should make the new footer demo usable without affecting other examples.src/patternfly/components/Table/table-tfoot.hbs (1)
1-7:table-tfoottemplate is consistent with existing table partialsThe
<tfoot>element,{{pfv}}table__tfootclass, optionaltable-tfoot--modifier, and rawtable-tfoot--attributehandling all match existing BEM and templating patterns (thead/tbody), and the@partial-blockyield keeps it flexible. Looks good.src/patternfly/components/Table/table.hbs (1)
9-11: New public flags map cleanly to existing modifiersWiring
table--IsPlain,table--HasStickyHeader, andtable--HasStickyFooterintosetModifierswithpf-m-plain,pf-m-sticky-header, andpf-m-sticky-footeris consistent with the rest of the API and matches how the examples now consume these features. No issues from a template or BEM perspective.src/patternfly/demos/Table/examples/Table.md (1)
218-219: Demos correctly migrated totable--HasStickyHeaderflagUpdating the sticky-header demos to use
table--HasStickyHeader=trueinstead of relying onpf-m-sticky-headerin the modifier keeps them aligned with the new public API while preserving behavior. Looks consistent in both the simple and scrollable/table--scrollable examples.Also applies to: 295-301
src/patternfly/components/Table/examples/Table.md (1)
1932-1932: Plain variant now uses the publictable--IsPlainflag correctlyUsing
table--IsPlain=truealongsidetable--modifier="pf-m-grid-md"aligns this example with the new API while still documenting.pf-m-plainin the usage table below. No behavior issues here.
082f632 to
c366f28
Compare
|
This PR has been automatically marked as stale because it has not had activity in the last 60 days. |
| } | ||
| } | ||
|
|
||
| > .#{$table}__tbody:last-of-type > .#{$table}__tr:last-of-type { |
There was a problem hiding this comment.
Because this executes whenever the sticky-footer modifier is present, what do you think about using the following incase someone doesn't end up using a tfoot (either accidentally or otherwise)? Otherwise that last border will be lost.
&:has(tfoot) > .#{$table}__tbody:last-of-type > .#{$table}__tr:last-of-type {
There was a problem hiding this comment.
Personally I could go either way. 2 downsides to that would be that 1) it increases the specificity, though shouldn't be a problem, and 2) the :has() selector isn't as performant as standard selectors, and tables tend to have a lot of nodes, and lots of nodes in :has() can make it slower. Tables often have a lot of rows and sometimes contain nested tables, and table performance is something I try to keep an eye on. That said, using a descendent selector like &:has(> tfoot) > .#{$table}__tbody:last-of-type > .#{$table}__tr:last-of-type { would probably mitigate any performance issues.
I would lean toward leaving it as-is, unless you can think of a valid use case where it could create a bug? If someone is using pf-m-sticky-footer without a tfoot I would probably just tell them to remove that class. WDYT - still think we should update it?
thatblindgeye
left a comment
There was a problem hiding this comment.
Can we also open a React followup for this if one doesnt exist
|
kmcfaul
left a comment
There was a problem hiding this comment.
Implementation lgtm, but have a question about the design.
Looking at the preview, I find the footer a bit hard to differentiate from a normal table row, especially when it's non-sticky / sticky but flush with the end of the table. My first reaction seeing the example was that the footer was missing until I looked more carefully at the bottom row, though I did quickly see it was footer after that.
I'm wondering if anyone from design has any thoughts about this?
8089b93 to
f627ca0
Compare
|
@kmcfaul one thing we talked about on Monday was removing the bottom border, so I just pushed that update. @lboehling @andrew-ronaldson any other updates you'd want to make? https://pf-pr-8034.surge.sh/components/table#table-footer FWIW here it is with a secondary and striped background color
|
kmcfaul
left a comment
There was a problem hiding this comment.
I like it better without the bottom border 👍
| &.pf-m-plain { | ||
| --#{$table}--BackgroundColor: transparent; | ||
| } |
There was a problem hiding this comment.
Should be able to remove this
| &.pf-m-sticky-footer { | ||
| > .#{$table}__tfoot { | ||
| position: sticky; | ||
| inset-block-end: 0; | ||
| z-index: var(--#{$table}--m-sticky-footer--ZIndex); | ||
| background: var(--#{$table}--BackgroundColor); | ||
|
|
||
| &::before { | ||
| position: absolute; | ||
| inset: 0; | ||
| z-index: var(--#{$table}--m-sticky-footer--border--ZIndex); | ||
| pointer-events: none; | ||
| content: ""; | ||
| border-block-start: var(--#{$table}--border-width--base) solid var(--#{$table}--BorderColor); | ||
| } | ||
| } | ||
|
|
||
| > .#{$table}__tbody:last-of-type > .#{$table}__tr:last-of-type { | ||
| border-block-end: 0; | ||
| } | ||
| } |
There was a problem hiding this comment.
Refactor this to sticky-base/sticky-stuck
| <tfoot class="{{pfv}}table__tfoot | ||
| {{#if table-tfoot--modifier}}{{table-tfoot--modifier}}{{/if}}" |
There was a problem hiding this comment.
| <tfoot class="{{pfv}}table__tfoot | |
| {{#if table-tfoot--modifier}}{{table-tfoot--modifier}}{{/if}}" | |
| <tfoot class="{{pfv}}table__tfoot{{#if table-tfoot--modifier}} {{table-tfoot--modifier}}{{/if}}" |
|
🎉 This PR is included in version 6.6.0-prerelease.7 🎉 The release is available on: Your semantic-release bot 📦🚀 |


Table footer example - https://pf-pr-8034.surge.sh/components/table#table-footer
Sticky footer example - https://pf-pr-8034.surge.sh/components/table#sticky-footer
Towards patternfly/pf-roadmap#282. This was demo code to show glass styles for table header/footer - cleaned it up to be a basic implementation for support for
<tfoot>. It does not have any special glass styling, it's just support for the table footer. It does support being sticky, like the table header/<thead>Fixes #8035
Summary by CodeRabbit
New Features
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.