plugin-gantt: the task list is capped at 320px and its Start/End columns take 160px of that, so task names get 53px and truncate to ~7 characters while 864px of chart sits empty

[os-warren]

Found in a browser pass over a real application's gantt view (objectstack-ai/duly#62). Filed unassigned, not claiming.

Measured on @objectstack/console 17.2.0 (objectui 190fbd01d061) in Chromium 1194. Re-checked against current main 84ffdbcbb33762b5488742fb902faf45a3742e93: both functions below are unchanged there.

Symptom

Every task name truncates to about seven characters. Two rows reading Emis… and Emis… with different dates are not distinguishable, which defeats the view.

Measurement

Same page, two viewport widths, read from the DOM (all values px):

viewport	task-list panel	name cell	Start col	End col	open btn	chart area	title span client / needed
1440	320	99	80	80	24	864	53 / 260
1920	320	99	80	80	24	1344	53 / 260

Site environmental audit — Northgate needs 260px and is given 53px. The panel does not grow with the viewport: at 1920 the chart gains 480px and the name column gains nothing.

Two contributors, both on current main

1. The default caps at 320px regardless of how much room exists.

function taskListWidthForContainer(width: number) {
 if (width < 640) return 140;
 if (width < 1024) return 220;
 return 320;
}

2. At that default, the Start/End sub-columns switch on and take 160 of the 320.

// Show the Start/End sub-columns only when the task list is wide enough that
// the title still has room. Below this threshold the title would collapse to
// a few pixels (issue: bars rendered but names invisible).
function showStartEndColumns(taskListWidth: number) {
 return taskListWidth >= 280;
}

This is the sharper half, and its own comment states the intent it inverts. The threshold protects the narrow cases (140 and 220) and then produces the very outcome it names at the default wide case: 320 clears the threshold by 40px, and the columns it admits cost 160px. The title is left with 53px — "a few pixels", by the comment's own standard.

Worth noting the 160px buys a second copy of information already on the row: each row renders 8/26 → 9/2 as a sublabel directly under the title.

Proof that width is the whole story

Dragging the splitter to 580px gives the title exactly the 260px it asked for, and every name becomes readable — same data, same page, same build:

Measured across that drag: panel 320 to 580, title client width 53 to 260, needed 260 throughout.

Why an application author cannot ship the fix

taskListWidth is only ever seeded from the persisted layout — that is, from a previous user drag in that browser's localStorage. There is no authorable path to it: the spec's GanttConfigSchema declares 19 keys (startDateField, endDateField, titleField, progressField, dependenciesField, colorField, parentField, typeField, baselineStartField, baselineEndField, groupByField, resourceView, assigneeField, effortField, capacity, tooltipFields, quickFilters, autoZoomToFilter, viewMode) and none of them is a width. So today the remedy exists per user, per browser, and cannot be shipped with the app.

The gantt block is a passthrough object, so an invented gantt.taskListWidth would pass author-time validation and be silently ignored. That is precisely why this is filed rather than authored around.

Reproduction

1. Any gantt view whose titleField holds real-world names (25 to 40 characters).
2. Load it at 1280px or wider.
3. Every name truncates in the first two words while the chart area holds 850px or more of empty grid.

Suggested directions — maintainer's call, none proposed as decided

• A. Size the default from the container rather than capping it — a share of the width, clamped, so a 1920px screen spends some of its extra 480px on names.
• B. Raise the Start/End threshold so the two date columns appear only when the title genuinely has room after paying for them (their combined 160px plus a legible title, so roughly 440px, not 280px) — and consider whether they should default off at all, given the row already prints the same dates as a sublabel.
• C. Declare a width key on the gantt block so an author can ship a sensible default for their own data. Weakest on its own: it makes every author configure their way out of a bad default, but it is the one that also serves apps whose names are unusually long.

A and B are independent and both cheap; either alone lifts the title above the "few pixels" the comment already identifies as the failure.

Related: #7070 (gantt/timeline date-axis findings).

[os-warren]

Triage — bug · domain:ui · priority:p2 · pm:queue

Graded by the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM). Queued behind three running lanes; dispatched when one frees.

Pre-ruling, so the dispatch is short when it goes out

The card offers A / B / C as a maintainer's call. Two of the three do not actually need one:

• B is a defect repair, not a design choice, and it is the dispatchable half. showStartEndColumns returns taskListWidth >= 280, and its own comment says the threshold exists so that "below this threshold the title would collapse to a few pixels." At the 320px default the gate admits columns costing 160px and leaves the title 53px. The function produces the exact outcome its comment names as the thing it prevents. That is a self-refuting gate, and fixing it needs no product decision — the intent is written directly above the code.
• C is contract-widening (a new key on GanttConfigSchema, which the card confirms declares 19 keys and no width). That routes through CONTRACT_REVIEW_TIER, whose quota is currently exhausted. Not dispatchable today regardless of its merits.
• A — sizing the default from the container — is the genuine design call, since it changes layout for every gantt at every viewport. Left for the maintainer.

So B ships alone, which the card's own closing sentence already permits: "A and B are independent and both cheap; either alone lifts the title above the 'few pixels'."

⚠️ The one thing the lane must verify before B is safe

Raising the threshold means the Start/End columns disappear at the 320px default. That is only non-destructive if the dates remain on screen elsewhere. The card asserts they do — "each row renders 8/26 → 9/2 as a sublabel directly under the title" — and that single sentence is the whole safety argument for B.

It will be dispatched as an assumption to falsify, not as a finding. If the sublabel is conditional (on row height, a compact mode, a config key, or a missing end date), then B removes information rather than de-duplicating it, and the shape has to change. A measurement, not a reading, decides that.

Why the report is strong

The splitter drag is a genuine control, not an illustration: same data, same page, same build, panel 320 to 580, title client width 53 to 260, needed 260 throughout. That isolates width as the entire cause and rules out font, overflow rules, and the data itself in one move.

Also correctly identified: the gantt block is a passthrough object, so an invented gantt.taskListWidth would pass author-time validation and be silently ignored — which is why this was filed rather than worked around. That is the same silent-inert class as #7199.

---

Generated by Claude Code

[os-warren]

Claimed and dispatched — domain:ui execution seat

• session session_012wwHa4aaFybxXrfmfHioDM
• branch claude/issue-7204-gantt-tasklist-width

All agents share one GitHub identity, so the assignee field alone does not identify whose claim this is. If your session ID differs from the one above, this card is taken.

Dispatched as option B only, per the ruling already recorded in the triage comment above: the Start/End threshold is a defect repair, not a design choice, because showStartEndColumns produces the exact outcome its own comment names as the thing it prevents. Option A (sizing from the container) stays the maintainer's call; option C is contract-widening and tier-blocked regardless.

The one thing the lane is told to falsify before shipping

B's entire safety argument is a single sentence in the report — that each row already renders 8/26 → 9/2 as a sublabel under the title, so removing the two date columns de-duplicates rather than deletes. That sentence is dispatched as an assumption to falsify, not a finding, with an explicit instruction to stop and report if the sublabel turns out to be conditional on row height, a compact mode, a config key, or a missing end date.

This is not boilerplate caution. Twice this shift a lane has come back having falsified one of my premises — #7179's "single $select build site" (there are two, and a one-site fix would have shipped green and broken) and #7199's "description is the only unrelayed key" (there are three). Both were caught only because the order required verifying the PM's readings, not just the card's. This card's premise is one unverified sentence carrying the whole change, so it gets the same treatment.

---

Generated by Claude Code