You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While verifying PR #2826 at wide viewport widths (3440px and 1440p), I noticed a substantial empty area inside .composer-left between the last chip and the right edge of .composer-box. Wanted to raise this as a question rather than presume a fix shape — it might be entirely intentional given how .composer-right and the send-button cluster live in real layouts, but the harness made the gap conspicuous and I wasn't sure if it had been considered.
This issue is paired with #2826 only by context — that PR's fix to chip-shrink at narrow widths is in v0.51.125 and resolves the original report cleanly. The widening behavior at the OTHER end of the viewport range is a separate observation.
Reproducer (minimal HTML)
The CSS slice below isolates the composer footer + left strip + right cluster. Save as .html and open in a browser — resize the window across the 1100px → 3440px range to see the gap inside .composer-left grow.
<!doctype html><html><head><metacharset="utf-8"><title>composer footer wide-width reproducer</title><style>body{background:#1C1B19;color:#FFF8DC;font-family:system-ui,sans-serif;margin:0;padding:24px;}
.composer-box{max-width:clamp(780px,60vw,1100px);background:#262420;border:1px solid rgba(255,255,255,.08);border-radius:14px;padding:12px;margin:0 auto;}
.composer-footer{display:flex;align-items:center;justify-content:space-between;gap:10px;padding:6px10px;}
.composer-left{display:flex;align-items:center;gap:4px;min-width:0;flex:1;overflow-x:auto;}
.composer-right{display:flex;gap:8px;align-items:center;flex-shrink:0;}
.chip{display:inline-flex;align-items:center;gap:6px;height:28px;padding:012px;border-radius:99px;background:rgba(0,0,0,.25);border:1px solid rgba(255,255,255,.08);color:#FFF8DC;font-size:12px;line-height:1;white-space:nowrap;flex:00 auto;}
.composer-ws-chip{max-width:284px;overflow:hidden;text-overflow:ellipsis;}
.composer-send{background:#C4884D;border:none;color:#1a1a1a;padding:8px14px;border-radius:99px;font-weight:600;cursor:pointer;}
.ctx{width:34px;height:34px;border-radius:50%;background:rgba(255,255,255,.06);}
.marker{position:fixed;top:8px;right:12px;background:#262420;border:1px solid rgba(255,255,255,.15);padding:6px10px;border-radius:6px;font-size:11px;font-family:monospace;color:#C4884D;line-height:1.5;text-align:right;}
</style></head><body><divclass="marker" id="m"></div><p>Resize the window. Watch the empty space inside <code>.composer-left</code> between "Sonnet 4.6" and the orange send button grow as the viewport widens.</p><divclass="composer-box"><divclass="composer-footer"><divclass="composer-left"><buttonclass="chip">Default profile</button><buttonclass="chip composer-ws-chip">/Users/foo/Documents/very/deep/nested/project-name</button><buttonclass="chip">Auto</button><buttonclass="chip">Tools</button><buttonclass="chip">Claude Sonnet 4.6</button></div><divclass="composer-right"><spanclass="ctx" title="context-usage ring placeholder"></span><buttonclass="composer-send">Send</button></div></div></div><script>functiontick(){varbox=document.querySelector('.composer-box');varleft=document.querySelector('.composer-left');varchips=left.querySelectorAll('.chip');varchipW=0;chips.forEach(function(c){chipW+=c.getBoundingClientRect().width;});varleftW=left.getBoundingClientRect().width;vargap=Math.max(0,leftW-chipW-16);// -16 for inter-chip gapsdocument.getElementById('m').innerHTML='window: '+window.innerWidth+'px<br>'+'composer-box: '+Math.round(box.getBoundingClientRect().width)+'px<br>'+'composer-left: '+Math.round(leftW)+'px<br>'+'chips total: '+Math.round(chipW)+'px<br>'+'empty space inside .composer-left: ~'+Math.round(gap)+'px';}window.addEventListener('resize',tick);tick();</script></body></html>
At 3440×1440 the empty-space readout shows roughly 400px sitting between the last chip and the .composer-right cluster — about 36% of the 1100px composer-box width.
So as .composer-box widens toward its clamp(780px, 60vw, 1100px) ceiling, .composer-left widens, the chips inside stay clustered at the start, .composer-right stays at the right edge, and the empty space inside .composer-left (between the rightmost chip and the .composer-right cluster) grows.
Why I'm asking instead of proposing
I'm not sure if this is:
(A) Intentional — the empty space is breathing room for future chips, or a deliberate "compact-actions, generous-canvas" UX choice, in which case this issue can close; OR
(B) Unconsidered side effect — the flex: 1 on .composer-left was set primarily to let it absorb extra space at narrower-but-still-wide widths, and at ultrawide widths the gap becomes more conspicuous than the design intended; OR
(C) Already considered and dismissed — there's a reason behind it I haven't surfaced.
If it's worth revisiting, a few shape options I can think of (just to seed discussion — not proposing any specifically):
Cap .composer-left's effective content width (e.g. .composer-left > *:last-child { margin-right: auto } to push subsequent content to the right, or a max-width on .composer-left itself)
Have .composer-right slide left to meet the chip cluster at wide widths (loses the "anchored to corner" affordance)
Add a subtle visual divider or fade at the gap edge so the empty space reads as "intentional canvas" rather than "missing content"
Keep current behavior — the empty space IS intentional canvas, no change
If (A) is the answer, happy to close. Just wanted to raise it explicitly so the wide-viewport case is on record.
Verification I can offer
Self-contained reproducer above runs in any browser at any width
Screenshot from my 3440×1440 setup attached below (showing the gap at maximum)
Will not file a paired PR until the maintainer signals the desired direction
AI Usage Disclosure
Reproducer HTML + CSS analysis + this issue body authored with Claude (Opus 4.7) assistance. The observation that triggered this draft came from a human reviewer on my side during manual verification of PR #2826.
What I noticed
While verifying PR #2826 at wide viewport widths (3440px and 1440p), I noticed a substantial empty area inside
.composer-leftbetween the last chip and the right edge of.composer-box. Wanted to raise this as a question rather than presume a fix shape — it might be entirely intentional given how.composer-rightand the send-button cluster live in real layouts, but the harness made the gap conspicuous and I wasn't sure if it had been considered.This issue is paired with #2826 only by context — that PR's fix to chip-shrink at narrow widths is in v0.51.125 and resolves the original report cleanly. The widening behavior at the OTHER end of the viewport range is a separate observation.
Reproducer (minimal HTML)
The CSS slice below isolates the composer footer + left strip + right cluster. Save as
.htmland open in a browser — resize the window across the 1100px → 3440px range to see the gap inside.composer-leftgrow.At 3440×1440 the empty-space readout shows roughly 400px sitting between the last chip and the
.composer-rightcluster — about 36% of the 1100px composer-box width.CSS analysis — where the behavior comes from
From master
static/style.css:The mechanism:
.composer-footeris aspace-betweenflex row — its two children sit at opposite ends.composer-lefthasflex: 1— it absorbs all horizontal slack.composer-righthasflex-shrink: 0— it stays its natural width.composer-leftareflex: 0 0 auto(post-fix(composer): stop chip wraps from compressing past their content (#2740) #2826) — they don't growSo as
.composer-boxwidens toward itsclamp(780px, 60vw, 1100px)ceiling,.composer-leftwidens, the chips inside stay clustered at the start,.composer-rightstays at the right edge, and the empty space inside.composer-left(between the rightmost chip and the.composer-rightcluster) grows.Why I'm asking instead of proposing
I'm not sure if this is:
flex: 1on.composer-leftwas set primarily to let it absorb extra space at narrower-but-still-wide widths, and at ultrawide widths the gap becomes more conspicuous than the design intended; ORIf it's worth revisiting, a few shape options I can think of (just to seed discussion — not proposing any specifically):
.composer-left's effective content width (e.g..composer-left > *:last-child { margin-right: auto }to push subsequent content to the right, or a max-width on.composer-leftitself).composer-rightslide left to meet the chip cluster at wide widths (loses the "anchored to corner" affordance)If (A) is the answer, happy to close. Just wanted to raise it explicitly so the wide-viewport case is on record.
Verification I can offer
AI Usage Disclosure
Reproducer HTML + CSS analysis + this issue body authored with Claude (Opus 4.7) assistance. The observation that triggered this draft came from a human reviewer on my side during manual verification of PR #2826.