Pull request overview

Adds a product spec for a proposed new st.column_config.ButtonColumn that enables clickable, per-row action buttons inside st.dataframe with Python callbacks.

Changes:

• Introduces a new product spec describing the ButtonColumn API, data format, and click-state semantics.
• Documents behavior for single-button cells vs multi-action dropdown cells, including Material icon label support.
• Includes alternatives considered and an implementation checklist.

Summary

This PR adds a product specification for st.column_config.ButtonColumn — a new column type that renders clickable buttons within st.dataframe cells, enabling row-level actions with Python callbacks. The PR contains a single new markdown file at specs/2026-03-26-button-column/product-spec.md and no code changes.

The spec proposes a data-driven approach where button labels come from column data (consistent with LinkColumn), supports single buttons (string) and dropdown menus (list of strings), uses the trigger value pattern for click state (like st.menu_button), and includes Material icon support.

All three reviewers (claude-4.6-opus-high-thinking, gemini-3.1-pro, gpt-5.3-codex-high) evaluated this PR and unanimously approved it.

Code Quality

Not applicable — this is a spec-only PR with no code changes.

The spec document is well-structured, clearly organized, and follows the product spec template with all required sections (Summary, Problem, Proposal, Checklist) plus valuable Alternatives Considered and Out of Scope sections. All three reviewers agreed the writing is clear and the spec provides a solid foundation for implementation.

API design alignment (reviewer consensus): The proposed API adheres well to Streamlit's API Design Principles:

• Simplicity First: Common usage requires minimal parameters.
• Consistency: Uses on_click (matching st.button), label, help, key (standardized vocabulary).
• Progressive Disclosure: Only label is positional; all others are keyword-only.
• Prefer Enums Over Booleans: type uses a Literal with three variants.
• Start Minimal: Future work (disabled buttons, custom colors, trailing icons) is explicitly deferred.

One inconsistency identified: The spec contradicts itself on st.data_editor support — the "Read-only" section (line 170) states buttons are "always read-only, even in st.data_editor", while the "Interaction with Other Features" section (lines 310-312) states ButtonColumn is "Not supported" and "only works with st.dataframe". This was identified by one reviewer and confirmed upon verification. See inline comment for details.

Test Coverage

Not applicable — this is a spec-only PR. No tests are expected or needed. All reviewers agreed that comprehensive test coverage (frontend unit tests, backend tests, E2E tests) should be required in the implementation PR.

Backwards Compatibility

No backwards compatibility concerns. All reviewers agreed this spec proposes a purely additive feature — a new column type added to st.column_config — with no modifications to existing APIs.

Security & Risk

No security concerns. This is a documentation-only change. The spec notes that callbacks execute user code, which follows the same pattern as all existing widget callbacks — no new attack surface is introduced. All three reviewers concurred.

External test recommendation

• Recommend external_test: No
• Triggered categories: None
• Evidence:
  • specs/2026-03-26-button-column/product-spec.md: Spec document only, no code changes affecting routing, auth, websocket transport, embedding, assets, storage, or security headers.
• Suggested external_test focus areas: None at this stage. External test needs should be reassessed when the implementation PR lands, particularly around embedding behavior and callback/session interactions in externally hosted deployments.
• Confidence: High (unanimous across all three reviewers)
• Assumptions and gaps: None — a spec document has zero runtime impact.

Accessibility

Not directly applicable to a spec document. However, all three reviewers flagged accessibility considerations for the future implementation:

• Buttons rendered on an HTML5 canvas (via glide-data-grid) may not be natively accessible to screen readers; the implementation should ensure proper ARIA annotations or alternative accessible interactions.
• Icon-only buttons (:material/icon_name:) need appropriate ARIA labels for screen readers.
• The dropdown menu for multi-action buttons should be keyboard-navigable and screen-reader compatible.
• Button style variants (primary/secondary/tertiary) should maintain sufficient color contrast ratios.

These are appropriate for the implementation PR rather than the spec, but could be noted as acceptance criteria.

Recommendations

1. Clarify st.data_editor behavior (all reviewers implicitly or explicitly flagged): Resolve the contradiction between "always read-only, even in st.data_editor" (line 170) and "Not supported... only works with st.dataframe" (lines 310-312). Choose one behavior and update both sections to be consistent.

2. Consider noting the novel callback-on-column-config pattern: This spec introduces callbacks (on_click, args, kwargs) and session state keys (key) on a column_config object — a new architectural pattern since existing column configs are purely declarative. A brief note acknowledging this or pointing to a companion tech spec would help reviewers evaluate feasibility.

3. Add accessibility acceptance criteria: Include explicit accessibility requirements (keyboard navigation, ARIA attributes, screen reader support) as acceptance criteria in the spec checklist, so they are tracked from the outset rather than addressed retroactively during implementation.

4. Consider documenting behavior for filtered/paginated dataframes: The spec addresses sorting (row indices refer to original positions) but doesn't mention behavior when rows are filtered or paginated. A brief note would future-proof the spec.

Verdict

APPROVED: Well-structured product spec that follows Streamlit's API design principles and spec guidelines. All three reviewers approved unanimously. The st.data_editor inconsistency should be resolved but is non-blocking — it can be addressed before or during implementation.

This is a consolidated AI review by claude-4.6-opus-high-thinking, synthesizing reviews from claude-4.6-opus-high-thinking, gemini-3.1-pro, and gpt-5.3-codex-high.

This review also includes 2 inline comment(s) on specific code lines.

Summary

This PR adds a product specification for st.column_config.ButtonColumn — a new column type for st.dataframe that renders clickable buttons within cells, enabling row-level actions (edit, delete, view details, etc.) with Python callbacks. The change consists of a single new markdown file (specs/2026-03-26-button-column/product-spec.md) with no code, frontend, protobuf, or test changes.

The spec proposes a data-driven approach where button labels come from column data (consistent with LinkColumn), supports single buttons (string) and dropdown menus (list of strings), uses the trigger value pattern for click state (like st.menu_button), and includes Material icon support.

Reviewer consensus: All three reviewers (claude-4.6-opus-high-thinking, gemini-3.1-pro, gpt-5.3-codex-high) approved this PR unanimously. No disagreements were found across any review dimension.

Code Quality

Not applicable — this PR contains only a spec document. All reviewers agreed the spec is well-structured, clearly organized, and follows the product spec template (specs/YYYY-MM-DD-template/product-spec.md) with all required sections. The document covers API shape, behavior, examples, alternatives considered, out-of-scope items, and a checklist — making implementation intent explicit and reviewable.

The spec follows the API design principles documented in specs/AGENTS.md:

• Simplicity First / Progressive Disclosure: Only label is positional; all other params are keyword-only.
• Consistency Over Novelty: Uses existing on_click/args/kwargs callback pattern from st.button.
• Prefer Enums Over Booleans: type uses Literal["primary", "secondary", "tertiary"].
• Start Minimal: Explicit out-of-scope list (disabled state, confirmation dialogs, custom colors, trailing icons).
• Standardized Vocabulary: Uses label, key, help — all standard names.

Test Coverage

Not applicable — no code changes are included. All reviewers agreed this is expected for a spec-only PR. The implementation PR(s) should include frontend unit tests, Python unit tests, and E2E coverage for click behavior, callback trigger semantics, sorting interactions, and CSV export exclusions described in the spec.

Backwards Compatibility

No backwards compatibility concerns (unanimous). This is a purely additive spec for a new column type. The proposed API does not alter any existing command signatures, and st.dataframe's public API requires no changes.

Security & Risk

No security risks in this PR (unanimous). It is a spec document only. All reviewers noted that the spec correctly identifies callback execution of user code as a consideration, which follows the standard risk profile of existing Streamlit widget callbacks. Residual risk is deferred to the implementation phase.

External test recommendation

• Recommend external_test: No
• Triggered categories: None
• Evidence:
  • specs/2026-03-26-button-column/product-spec.md: Documentation-only change; no runtime, networking, auth, embedding, asset serving, routing, WebSocket, or security header code is modified.
• Suggested external_test focus areas: None at this stage. External test coverage should be reassessed when the implementation PR lands.
• Confidence: High (unanimous across all reviewers)
• Assumptions and gaps: Assessment assumes this PR contains only the documented spec file and no hidden runtime changes outside the presented diff.

Accessibility

Not directly applicable to this spec-only PR (unanimous). For the future implementation, reviewers collectively highlighted these considerations:

• Keyboard navigability for buttons within dataframe cells (focus management, tab order).
• Screen reader announcements for button clicks and dropdown menus.
• Sufficient color contrast for all three button style variants (primary, secondary, tertiary).
• ARIA attributes for the dropdown menu (three-dot icon) including aria-haspopup, aria-expanded, and menu item roles.
• Proper ARIA labels for icon-only actions.

These should be addressed in the tech spec or during implementation.

Recommendations

1. Clarify on_click callback signature: The spec shows callbacks accessing st.session_state[key] to get click info, but doesn't explicitly state whether row and label are also passed as arguments to the callback. Consider documenting the exact callback signature or confirming it follows the standard pattern where click data is only available via session state.

2. Add accessibility notes to the spec: Consider adding a brief section on keyboard navigation and screen reader support expectations for buttons in cells and the dropdown menu. This was a shared concern across all reviewers.

3. Consider column-level disabled parameter: While per-cell disabled state is listed as out-of-scope, a column-level disabled: bool parameter (to disable all buttons) would be consistent with other Streamlit widgets and low-effort to include. Non-blocking.

4. Clarify scope of "No changes to st.dataframe": This likely refers to the public API signature, but the implementation will require internal changes. The tech spec should clarify the implementation scope.

5. Require follow-up implementation PR to include explicit unit and E2E coverage for the specified interaction contract, including click behavior, callback trigger semantics, sorting interactions, and CSV export exclusions.

Verdict

APPROVED: All three reviewers unanimously approved. This is a well-structured, low-risk product spec that follows the template and API design principles. The data-driven approach is consistent with existing column types, the API surface is minimal, and alternatives are thoroughly documented. All recommendations above are non-blocking suggestions for the implementation phase.

This is a consolidated AI review by claude-4.6-opus-high-thinking, synthesizing reviews from: claude-4.6-opus-high-thinking, gemini-3.1-pro, gpt-5.3-codex-high. All expected models completed their reviews successfully.