Pull request overview

Adds a new product spec describing the proposed resizable: bool = False parameter for st.columns, enabling client-side drag-to-resize of adjacent columns without triggering reruns.

Changes:

• Introduces a product spec for resizable columns, including the proposed API shape and parameter semantics.
• Documents expected interaction behavior (drag, hover affordance, double-click reset, keyboard/touch support).
• Provides examples, edge cases, and an out-of-scope list to bound the initial feature.

Summary

This PR adds a product specification document (specs/2026-04-08-resizable-columns/product-spec.md) for a new resizable: bool = False parameter on st.columns. The feature would allow users to drag-to-resize column borders client-side without triggering a script rerun. No code, tests, or dependencies are modified — this is a documentation-only change.

All three reviewers (claude-4.6-opus-high-thinking, gemini-3.1-pro, gpt-5.3-codex-high) completed their reviews and unanimously approved.

Code Quality

Consensus: The spec is well-structured and follows the established template (frontmatter, Summary, Problem, Proposal, Checklist). The writing is clear and the behavior section is thorough, covering hover indicators, drag interaction, keyboard support, touch devices, narrow viewports, edge cases, and state persistence.

Two structural gaps were identified by a majority of reviewers (claude, gpt-5.3-codex):

1. Missing "Alternatives Considered" section. The spec guidelines state "For non-trivial APIs, show 2-3 options with tradeoffs." The spec should discuss alternatives (e.g., resizable: bool vs resize_mode: Literal["none", "drag"] | None enum, and whether this belongs on st.columns specifically vs a more general container capability) and explain why a boolean was chosen. This is particularly relevant given API Design Principle #16 ("Prefer Enums Over Booleans") and the future work items that could motivate additional modes.

2. Missing GitHub issue links or user demand evidence. The spec guidelines emphasize "Link GitHub issues with upvote counts" and "Show concrete user pain points." The Problem section describes plausible use cases but does not reference any GitHub issues, forum posts, or concrete user requests.

Test Coverage

Not applicable — spec-only PR with no behavioral changes. All reviewers agreed no tests are required for this PR. For the eventual implementation PR, coverage should include frontend unit tests (resize interactions, keyboard behavior, min-width constraints), backend API tests (parameter validation), and e2e tests (drag resize, responsive stacking, persistence/reset behavior).

Backwards Compatibility

Consensus: No breaking changes. The proposed API is additive with resizable=False as the default, preserving existing behavior. The spec document itself introduces no behavioral change.

Security & Risk

Consensus: No security concerns. This is a Markdown document addition with no code execution, dependency changes, or runtime impact.

External test recommendation

• Recommend external_test: No
• Triggered categories: None
• Evidence:
  • specs/2026-04-08-resizable-columns/product-spec.md: New Markdown spec file only; no changes to runtime code, routes, auth, websocket transport, embedding, asset serving, storage, or browser security policies.
• Suggested external_test focus areas: N/A (re-assess in the implementation PR, especially if resize behavior touches embedding or cross-origin layout behavior)
• Confidence: High
• Assumptions and gaps: None — a pure documentation PR has zero external-test risk. All three reviewers agreed unanimously.

Accessibility

The spec positively calls out keyboard support (Arrow Left/Right for 10px increments) and cursor feedback (col-resize). Two reviewers (claude, gpt-5.3-codex) recommended strengthening the accessibility details for the implementation:

• ARIA attributes: The spec should mention appropriate ARIA roles (e.g., role="separator" with aria-orientation="vertical") for the resize handles, so screen readers can identify them.
• Focus visibility: The spec mentions keyboard support but doesn't describe the visual focus indicator on the resize handle. A visible focus ring is important for keyboard-only users.
• Screen reader announcements: Consider whether resizing should announce the new column widths (e.g., via aria-valuenow/aria-valuemin/aria-valuemax on the separator).

One reviewer (gemini) marked accessibility as N/A since there are no frontend changes in this PR, which is technically correct, but the majority view was that the spec should define these requirements so they become testable acceptance criteria for the implementation.

Recommendations

1. Add an "Alternatives Considered" section discussing at least: (a) resizable: bool vs resize_mode: Literal[...] enum, and (b) whether this belongs on st.columns specifically vs a more general container capability. Reference API Design Principle #16. (Raised by 2/3 reviewers)
2. Add GitHub issue links or user demand evidence to the Problem section. If no issues exist, note that explicitly so reviewers can assess prioritization. (Raised by 2/3 reviewers)
3. Expand accessibility details to mention ARIA roles (role="separator"), focus indicator styling, and screen reader announcements for the resize handles. This ensures the implementation has testable a11y acceptance criteria. (Raised by 2/3 reviewers)
4. Clarify the stacking reset behavior in "State persistence": resized widths resetting when columns stack/unstack on window resize could frustrate users who briefly resize their browser. Consider whether widths should be preserved across stack/unstack transitions if the column count hasn't changed. (Raised by 1/3 reviewers)

Verdict

APPROVED: Well-written product spec that follows the established template and proposes a clean, backward-compatible API. All three reviewers approved unanimously. The recommendations above are improvements for spec completeness but do not block merging as a draft spec for discussion.

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 4 inline comment(s) on specific code lines.

Summary

This PR adds a product specification for a new resizable: bool = False parameter on st.columns (specs/2026-04-08-resizable-columns/product-spec.md). The spec proposes enabling client-side drag-to-resize between adjacent columns, including hover indicators, double-click reset, keyboard support, touch support, and ARIA accessibility attributes. The change is a single new markdown file with no code, test, or protobuf modifications.

Reviewer consensus: All three reviewers (claude-4.6-opus-high-thinking, gemini-3.1-pro, gpt-5.3-codex-high) approved the PR unanimously. No critical or blocking issues were raised.

Code Quality

Not applicable — this is a documentation-only (spec) PR. All reviewers agree the spec follows the established directory convention (specs/YYYY-MM-DD-feature-name/product-spec.md), includes the required YAML frontmatter, and is well-organized with clear writing and consistent markdown formatting.

Test Coverage

Not applicable — no code changes to test. The PR description accurately states "Documentation-only changes (spec file), no behavior modifications." One reviewer (gpt-5.3-codex-high) helpfully noted that future implementation should include frontend unit tests and e2e scenarios covering drag, keyboard, touch, reset, and responsive stack/unstack behavior.

Backwards Compatibility

All reviewers agree: the proposed API is additive with a new optional resizable parameter defaulting to False. No existing behavior changes. The current st.columns API signature is fully preserved.

Security & Risk

No security concerns identified by any reviewer. The spec describes a pure client-side feature using existing DOM APIs and React state. No new dependencies, server endpoints, authentication changes, or external requests are involved.

External test recommendation

• Recommend external_test: No (unanimous across all reviewers)
• Triggered categories: None
• Evidence:
  • specs/2026-04-08-resizable-columns/product-spec.md: New spec file only; no code, routing, auth, WebSocket, embedding, asset serving, CORS, storage, or security header changes.
• Suggested external_test focus areas: None at this time. External test coverage should be reassessed when the implementation PR lands (particularly for embedded iframe behavior and responsive resize interactions across hosting environments).
• Confidence: High
• Assumptions and gaps: Assessment is based on the current docs-only diff; recommendation should be revisited when executable changes land.

Accessibility

The spec includes thoughtful accessibility considerations that all reviewers praised: role="separator" with aria-orientation="vertical", aria-valuenow/aria-valuemin/aria-valuemax attributes, keyboard arrow-key support with 10px increments, and visible focus indicators meeting WCAG 2.1 requirements. These should be verified against the actual implementation when the feature is built.

Recommendations

1. Add an "Alternatives Considered" section (agreed: claude-4.6-opus-high-thinking, gpt-5.3-codex-high). The spec guidelines recommend "Present Options, Not Edicts" with 2-3 options and tradeoffs. This should cover parameter naming (resizable vs resize_mode), type choice (bool vs Literal enum per Principle 16), and any UX alternatives considered. Gemini did not raise this, but the recommendation aligns with the spec template guidelines.

2. Add GitHub issue links (raised by claude-4.6-opus-high-thinking). The Problem section lists use cases but provides no links to related issues or community requests. Linking to discussions or feature requests would strengthen the justification, per spec guidelines.

3. Clarify the state reset tradeoff on viewport stack/unstack (raised by claude-4.6-opus-high-thinking). Widths resetting when columns stack and unstack could frustrate users who briefly resize past the 640px threshold. The spec should document this as a deliberate tradeoff with rationale, or consider preserving state across transitions.

These are all non-blocking suggestions to improve spec quality before implementation begins.

Verdict

APPROVED: Well-structured product spec that follows the established template and covers behavior, edge cases, accessibility, and scope clearly. All three reviewers approved unanimously with no critical issues. The recommendations above (alternatives section, issue links, state reset rationale) would strengthen the spec but are not blockers for merging a documentation-only PR.

Consolidated from 3/3 expected reviews (claude-4.6-opus-high-thinking, gemini-3.1-pro, gpt-5.3-codex-high). No models failed to complete review. Consolidated by claude-4.6-opus-high-thinking.

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