feat(table): add widths option to control column sizes

[d3m1d0v]

Description

Adds per-table column width control via |:{widths="200px auto 10%"} option syntax, rendered as <colgroup>/<col> HTML elements.

Example:

#|
|:{widths="30px auto 100px"}
|| A | B | C ||
|#

Specifics:

• Option line format: |:{key="value"}
• Multiple option lines allowed, each parsed independently and merged (later values override earlier)
• widths value is space-separated CSS values (e.g., 30px auto 100px)
• Fewer widths than columns → pad missing with auto; more widths → ignore extras
• Empty widths value → no <colgroup> rendered
• Width rendered in style="width:..." attribute
• No validation for values

[yc-ui-bot]

Summary

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Other ❓	Flaky 🍂	Duration ⏱️
174	154	0	20	0	0	1m 51s

_{🎉 No failed tests in this run.}

Github Test Reporter by CTRF 💚

[yc-ui-bot]

Summary

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Other ❓	Flaky 🍂	Duration ⏱️
177	157	0	20	0	0	1m 42s

_{🎉 No failed tests in this run.}

Github Test Reporter by CTRF 💚

[sonarqubecloud]

Quality Gate passed

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
87.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[yc-ui-bot]

Summary

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Other ❓	Flaky 🍂	Duration ⏱️
177	157	0	20	0	0	1m 53s

_{🎉 No failed tests in this run.}

Github Test Reporter by CTRF 💚

[makhnatkin]

I suggest we formalize the syntax rules for all table options before we design each feature separately.
This will help us stay consistent and catch edge cases early.

Proposed rules

Syntax shape

• Always {curly braces} with key="value"
• Always double quotes — no shorthand, no bare booleans
• Table-level options: |:{key="value"}
• Cell-level options: Content {key="value"}
• kebab-case everywhere
• Common prefix for related properties (header / header-sticky)

Values

• CSS-like wherever possible (px, %, auto, color names, sticky)
• Space-separated list → maps to columns by position (widths="30px auto 100px")
• Colon pairs → index:type mapping (sortable="1:text 3:number")

Option lines

• After #|, before first || row
• Multiple |:{...} lines allowed
• Parsed independently, merged; later values override earlier
• Multiple keys per line OK: |:{header="1" header-sticky="true"}

Cell attrs

• At end of cell content, before delimiter
• Stripped from content, applied to <td>

Rendering

• Table options → data-* on <table> or structural changes (<colgroup>, <thead>)
• Cell options → data-* on <td>
• Runtime features (sorting, filtering) → data-*

Compatibility

• Must not break existing tables
• Must not conflict with markdown (links, code, blockquotes)

[makhnatkin]

Following these rules, the syntax for each feature could look like this:

Widths

#|
|:{widths="30px auto 100px"}
|| A | B | C ||
|| 1 | 2 | 3 ||
|#

Cell background

#|
|| OK {cell-bg="green"} | Warning {cell-bg="#fff3cd"} | Error {cell-bg="red"} ||
|#

Header + sticky

#|
|:{header="1" header-sticky="true"}
|| Name | Score ||
|| Alice | 95 ||
|| Bob | 87 ||
|#

Merge cells (existing, no changes)

#|
|| Group | Item | Value ||
|| A | x | 1 ||
|| ^ | y | 2 ||
|| Total | > | 3 ||
|#

Sorting

#|
|:{header="1"}
|:{sortable="1:text 3:number" sort-default="3:desc"}
|| Name | Team | Score ||
|| Ann | A | 10 ||
|| Bob | B | 8 ||
|#

Filtering

#|
|:{header="1"}
|:{filterable="1:text 2:select 3:number"}
|| Name | Status | Score ||
|| Ann | open | 10 ||
|| Bob | closed | 8 ||
|#

[makhnatkin]

And combinations of these features could look like this:

1. Styled report table

#|
|:{widths="200px auto 100px"}
|:{header="1" header-sticky="true"}
|| Name | Status | Score ||
|| Alice | done {cell-bg="green"} | 95 ||
|| Bob | blocked {cell-bg="red"} | 42 ||
|#

2. Sortable table with merged cells

#|
|:{header="1"}
|:{sortable="1:text 3:number"}
|| Team | Member | Score ||
|| Frontend | Ann | 10 ||
|| ^ | Bob | 8 ||
|| Backend | Carol | 12 ||
|#

3. Full-featured table

#|
|:{widths="150px auto 80px 80px"}
|:{header="1" header-sticky="true"}
|:{sortable="1:text 3:number 4:number" sort-default="4:desc"}
|:{filterable="1:text 2:select"}
|| Name | Department | Q1 | Q2 ||
|| Alice | Engineering {cell-bg="#e8f5e9"} | 95 | 98 ||
|| Bob | Design {cell-bg="#e3f2fd"} | 87 | 91 ||
|| Carol | Engineering {cell-bg="#e8f5e9"} | 92 | 88 ||
|#

4. Simple colored status table

#|
|:{widths="auto 120px"}
|| Task | Status ||
|| Deploy v2.1 | done {cell-bg="green"} ||
|| Fix login bug | in progress {cell-bg="yellow"} ||
|| Update docs | blocked {cell-bg="red"} ||
|#

[makhnatkin]

I also noticed some design questions that need a separate discussion.

Sticky: property name vs value?

Two possible approaches:

Option A — value of header:

|:{header="sticky"}

Option B — separate boolean property:

|:{header="1" header-sticky="true"}

Option B is more flexible, but more verbose. Option A is shorter, but mixes semantics (what is a header) with behavior (how it behaves).

Sticky columns and rows in the future

Today we only talk about sticky header. But in the future a user may want to:

• Freeze column 1 and column 2 (like Excel "freeze panes")
• Freeze the header row AND the first column at the same time
• Freeze a specific row (not just the first one)

If we choose header="sticky" now, we have no clean way to express "sticky columns" later. With separate properties it could grow naturally:

|:{header="1" header-sticky="true"}
|:{sticky-cols="1 2"}

or even:

|:{sticky-rows="1"}
|:{sticky-cols="1 2"}

[d3m1d0v]

I also noticed some design questions that need a separate discussion.

Sticky: property name vs value?

...

Sticky columns and rows in the future

This is outside the scope of the current PR