✅ PR preview is ready!

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

Summary

This PR introduces a new width="auto" parameter as the default for st.markdown(). When set to "auto", the width adapts based on the container context:

• Vertical containers: behaves like width="stretch" (100% width)
• Horizontal containers: behaves like width="content" (fit-content width)

The implementation works by omitting the widthConfig from the protobuf message when width="auto", and then handling this case in the frontend's ElementNodeRenderer by checking the FlexContext to determine the layout direction.

Code Quality

The implementation is clean and follows existing patterns in the codebase:

1. Backend (lib/streamlit/elements/markdown.py): The change is minimal and well-contained. The conditional logic at lines 184-188 correctly handles the "auto" case by not setting a widthConfig, allowing the frontend to determine the appropriate width.

2. Frontend (frontend/lib/src/components/core/Block/ElementNodeRenderer.tsx): Lines 436-448 correctly implement the container-aware sizing using the existing FlexContext pattern. The code adds a block scope {} for the markdown case (line 436) to properly scope the config variable, which is good practice.

3. Documentation: The docstring is well-updated with the new "auto" option and clearly explains the behavior.

Minor note: The type annotation Width | Literal["auto"] at line 47 is correct but creates a slight inconsistency since Width is defined as int | Literal["stretch", "content"] in layout_utils.py. Consider whether "auto" should be added to the Width type alias for consistency across the codebase in a follow-up.

Test Coverage

The test coverage is good but could be improved:

Python Unit Tests (lib/tests/streamlit/elements/markdown_test.py):

• test_st_markdown_default_width (lines 97-107): Tests that the default produces no width config ✓
• test_st_markdown_auto_width (lines 109-119): Tests explicit width="auto" ✓
• test_st_markdown_explicit_stretch_width (lines 121-131): Tests that explicit stretch still works ✓
• Good use of negative assertions (lines 105-107, 117-119) to verify neither stretch nor content is set ✓

Frontend Unit Tests (frontend/lib/src/components/elements/Markdown/Markdown.test.tsx):

• Integration tests for ElementNodeRenderer with different FlexContext configurations ✓
• Tests cover horizontal layout with fit-content (lines 406-426) ✓
• Tests cover vertical layout with 100% width (lines 428-448) ✓
• Tests cover explicit width configs (useStretch, useContent, pixelWidth) ✓
• Uses waitFor pattern for async assertions ✓

Missing Coverage:

• No E2E test specifically for the auto width behavior in horizontal layouts (e.g., st.columns). The existing st_markdown.py tests headers in columns but doesn't explicitly test the new auto width behavior. While the unit tests are comprehensive, an E2E test would provide full-stack validation of this user-facing behavior change.

Backwards Compatibility

This is a breaking change in behavior - the default width for st.markdown() changes from "stretch" to "auto":

• Before: st.markdown("text") in a horizontal layout (e.g., inside st.columns) would stretch to fill the column width.
• After: st.markdown("text") in a horizontal layout will shrink to fit its content.

This change is intentional and improves the default experience for markdown in horizontal layouts. Users who relied on the stretch behavior can explicitly use width="stretch" to restore it.

The change is semantically backwards compatible:

• All existing width options ("stretch", "content", integer pixels) still work
• Users can explicitly opt into the old behavior with width="stretch"

Note: The st.caption() and st.latex() functions retain "stretch" as their default, maintaining consistency for those elements.

Security & Risk

No security concerns identified. This is a purely visual/layout change with no impact on:

• Data handling
• Authentication/authorization
• External system interactions
• User input processing

Risk Assessment: Low. The change is well-scoped and the fallback to explicit width="stretch" provides a clear migration path for any affected users.

Accessibility

No accessibility concerns. The change:

• Does not affect any interactive elements
• Does not modify ARIA attributes
• Does not change focus handling
• Does not impact screen reader behavior

The width changes are purely visual and do not affect the semantic structure or accessibility tree of the rendered content.

Recommendations

1. Consider adding an E2E test for the auto width behavior in horizontal layouts to provide full-stack validation. This could be added to e2e_playwright/st_markdown.py:

   # Example test case
   col1, col2 = st.columns(2)
   with col1:
       st.markdown("Auto width markdown")  # Should be fit-content
   with col2:
       st.markdown("Stretch markdown", width="stretch")  # Should be 100%

2. Minor: Consider updating the existing snapshot tests in st_markdown_test.py (e.g., test_match_snapshot_for_columns) to explicitly verify the auto width behavior, as these tests use markdown in columns and will now produce different visual results.

3. Documentation note: The release notes should clearly communicate this default behavior change to help users understand why their horizontal layouts might look different after upgrading.

Verdict

APPROVED: The implementation is clean, well-tested with unit tests, and follows existing codebase patterns. The breaking change in default behavior is intentional and improves the user experience for markdown in horizontal layouts. The ability to explicitly set width="stretch" provides a clear migration path for any affected users. The missing E2E test is a minor gap that could be addressed in a follow-up.

This is an automated AI review using opus-4.5-thinking. Please verify the feedback and use your judgment.

No E2E test specifically for the auto width behavior in horizontal layouts (e.g., st.columns). The existing st_markdown.py tests headers in columns but doesn't explicitly test the new auto width behavior. While the unit tests are comprehensive, an E2E test would provide full-stack validation of this user-facing behavior change.

I decided against adding this since the styling/visuals are the same as "stretch" and "content" which are already tested, it is the switching behaviour that differs and is covered in the new tests.

📈 Frontend coverage change detected

The frontend unit test (vitest) coverage has increased by 0.0900%

• Current PR: 86.6000% (13868 lines, 1858 missed)
• Latest develop: 86.5100% (13875 lines, 1871 missed)

🎉 Great job on improving test coverage!

📊 View detailed coverage comparison

@sfc-gh-bnisco thinking about this more, I have decided to remove the cache because it feels like over-engineering when, looking at the charts you have mentioned, it doesn't seem like there is any evidence of a regression (let me know if you observed differently, but below is my analysis).

I traced through the two benchmarks linked. The basic_app test uses st.title, st.button, st.markdown, and st.write — all of which resolve to ElementContainerConfig.DEFAULT (a static constant). None of them create new config objects, so the data from that test isn't attributable to this change. The mega_tester_app graph shows high per-run variance (boxes span ~200-500 units against a ~6000ms baseline) with no visible step change at the commit boundary — the oscillation pattern is consistent before and after.

What I did instead: Added FULL_WIDTH, FIT_CONTENT_ELEMENT, and LARGE_OVERFLOW_VISIBLE as static constants, which covers the majority of call sites with zero overhead and guaranteed referential stability. The remaining ~4 conditional call sites use a ternary to select a static constant in the common case and only fall back to new ElementContainerConfig(...) when runtime conditions require it.