✅ 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.

✅ PR preview is ready!

Summary

This PR adds support for a custom CSS color directive in Streamlit's markdown rendering. Users can now write :color[text]{foreground="#FF5733" background="#000000"} to apply arbitrary CSS colors (hex, rgb, rgba, hsl, hsla, named colors) to text foreground and background. The implementation:

• Adds a new isValidCssColor() validation function that delegates to color2k's parseToRgba (an existing project dependency) for secure color validation.
• Extends the createRemarkColoringAndSmall remark plugin to handle the :color directive with foreground and background attributes.
• Reuses existing stMarkdownColoredText and stMarkdownColoredBackground CSS classes for consistent styling.
• Adds comprehensive unit tests and updates E2E snapshots for visual regression coverage.

Code Quality

The code is clean, well-structured, and follows the existing patterns in StreamlitMarkdown.tsx. Specific observations:

1. Good pattern reuse: The new handler mirrors the structure of the existing color directive handlers (setting data.hName, data.hProperties, etc.) and reuses the same CSS classes (stMarkdownColoredText, stMarkdownColoredBackground).

2. Placement is correct: The new handler is placed before the colorMapping.has(nodeName) check at line 746, ensuring that :color[text]{foreground="..."} is caught before reaching the named-color handler. Since "color" is not a key in colorMapping, this doesn't change existing behavior for predefined color names like :red[] or :blue[].

3. Inline style usage: The frontend AGENTS.md recommends avoiding inline style props in favor of Emotion styled components. However, this code operates at the HAST (markdown AST) level during remark processing, where Emotion components aren't applicable. The existing predefined-color handler uses the exact same data.hProperties.style approach (line 751), so this is consistent with the codebase.

4. Minor note on node.attributes check (line 682): In the remark-directive AST, node.attributes is always an object (possibly empty {}) for text directives, making the && node.attributes check always truthy when nodeName === "color". This means :color[text] without any attributes will also be intercepted by this handler. The resulting behavior (rendering as a plain <span>) is actually better than the previous behavior (the unsupported-directive cleanup would mangle it to just :color, losing the [text] content). This is a minor improvement, not a bug.

Test Coverage

Unit tests are well-done:

• isValidCssColor: Thorough parameterized tests covering hex (3/4/6/8-digit), rgb/rgba, hsl/hsla, named colors, empty string, invalid formats, and security attack vectors (XSS, CSS expressions).
• Custom color directive rendering: Tests for foreground-only, background-only, both colors, 3-digit hex, named colors, invalid color graceful degradation, and XSS rejection.

E2E tests: The custom color examples are added to the mixed markdown block (st_markdown.py line 259-260), which is covered by the themed snapshot test test_many_elements_in_one_block. Updated snapshots across all three browsers and both themes.

Potential gaps (minor, non-blocking):

• No unit test for :color[text]{foreground="red" background="notacolor"} (one valid, one invalid) — verifying that partial validity still applies the valid color correctly. The implementation handles this correctly, but a test would document the expected behavior.
• No unit test for rgb() format in the directive (e.g., :color[text]{foreground="rgb(255,0,0)"}), though isValidCssColor tests do cover rgb() validation.
• No unit test for :color[text] or :color[text]{} (no attributes) — confirming content is preserved as a plain span.

Backwards Compatibility

No breaking changes. The existing named-color directives (:red[], :blue[], etc.) and their background variants are unaffected because:

• The new handler only intercepts nodeName === "color", and "color" is not a key in the colorMapping.
• The new handler runs before the colorMapping.has(nodeName) check, but returns early so it doesn't interfere with subsequent handlers.

The only behavioral change is for the edge case :color[text] (without attributes), which previously rendered as the literal text :color (losing the bracket content). It now renders the full text content in a <span>, which is an improvement.

Security & Risk

Security is well-addressed:

• The isValidCssColor() function (line 651-658) delegates to color2k's parseToRgba(), which strictly parses only valid CSS color values. It rejects anything containing semicolons, url(), expression(), var(), javascript:, or other non-color content.
• Validated color values are interpolated into property-specific CSS declarations (color: ${foreground}, background-color: ${background}), limiting the injection surface further.
• The test suite explicitly covers javascript:alert(1) and expression(alert(1)) attack vectors.
• color2k is an existing, widely-used dependency already in the project (used across 20+ files for theme operations).

Risk assessment: Low. The validation approach is defense-in-depth: even if a color string somehow passed validation, it would be placed in a color: or background-color: CSS property context, limiting exploitability. The PR has a security-assessment-completed label.

Accessibility

The custom color directive uses the same HTML structure and CSS classes as the existing predefined color directives — <span> elements with stMarkdownColoredText or stMarkdownColoredBackground classes. No new interactive elements are introduced.

One consideration: custom foreground/background colors could create contrast issues for users with visual impairments (e.g., light text on light background). However, this is inherent to the feature request and is the author's responsibility when using custom colors, similar to how raw CSS works. No automated enforcement is practical here.

Recommendations

1. Consider adding a unit test for mixed valid/invalid attributes to document the partial-validity behavior. For example, :color[text]{foreground="red" background="notacolor"} should apply only the foreground color and use the stMarkdownColoredText class. This is non-blocking since the implementation handles it correctly.

2. Consider adding a unit test for :color[text] without attributes (or with empty attributes {}). This edge case now renders as a plain <span> (content preserved), which is better than the previous behavior, but documenting it in a test would be valuable.

3. (Nit) The condition on line 682 nodeName === "color" && node.attributes could be simplified to just nodeName === "color" since node.attributes is always truthy for remark-directive text directives. However, keeping it adds clarity about the intent (this handler is for the attribute-based syntax), so this is purely a style observation.

Verdict

APPROVED: Clean, well-tested implementation that adds custom CSS color support to markdown directives with solid security validation via an existing dependency. The code follows existing patterns, introduces no breaking changes, and has comprehensive unit test coverage.

This is an automated AI review by opus-4.6-thinking.