Matrix inputs: support curly HTML brackets

[adamant-pwn]

Summary

The question-level matrixparens option already accepts {, and STACK's TeX output renders matrices with curly braces. The fixed and variable-size HTML matrix inputs currently fall back to square brackets for that value.

This adds a matrixcurlybrackets style and selects it for both input types and their API metadata. The brace is stored as a small STACK plugin SVG and used as a CSS mask, so it scales to the input height while keeping a stable stroke width and inheriting the surrounding text colour. The same rule is included in styles.css and mobile.css.

There is no new question option or migration. Existing square, round, bar and no-bracket rendering is unchanged.

Screenshots

Fixed 2 × 2, fixed 4 × 1 and variable-size inputs rendered by a local patched STACK instance:

The existing square and round choices alongside the new curly rendering:

These were captured from the local STACK API image 2025102100 with the patch applied; each widget was produced by the API renderer rather than reconstructed as static HTML.

Verification

• Added focused rendering/API tests for fixed and variable-size inputs with matrixparens: '{'.
• PHP syntax checks pass for both renderer classes and their test files.
• Rendered locally through the standalone STACK API with fixed 2 × 2, fixed 4 × 1 and variable-size inputs.
• Compared square, round and curly settings side by side; the existing styles remain unchanged.
• Verified left-to-right and right-to-left placement in a browser.
• Verified in a browser accessibility snapshot that the empty CSS pseudo-elements and mask add no accessible node or text; the matrix table, cells and inputs remain exposed normally.

[sangwinc]

Wow! Thanks @adamant-pwn that's been on my list for a very long time. Thank you for finally sorting this out.

[christianp]

Is the shape of the brackets exposed to the accessibility tree at all?

[adamant-pwn]

No; like the existing square, round and bar styles, it is CSS-only. matrixparens is a presentation option and does not change the input value, so I'd treat the brackets as decorative. If the delimiter style should be announced, it would be better to handle all styles and both matrix input types consistently in a follow-up PR rather than special-case curly braces here.

[sangwinc]

Is the shape of the brackets exposed to the accessibility tree at all?

Do you have a recommendation with this issue @christianp?

[christianp]

If the brackets were separate elements, instead of styled pseudoselectors, you could add an aria-label attribute describing the shape with something like "curly bracket" or "parenthesis".