On a high-PPI, small-diagonal panel (reported case: 3840x2160 laptop screen, Chrome/Windows, OS display scaling at 100%), the rail (left icon strip) and surrounding chrome render so small at 100% browser zoom that they're hard to see or click. Zooming the browser to ~175% makes it usable.
Confirmed this isn't a layout/functional bug: reproduced with vite --mode mock in headless Chrome at the same 3840x2160 viewport and inspected computed styles. .rail comes out to exactly the CSS-defined 52px width (--rail-width in src/ui/tokens.css), correctly positioned, not covered by anything (elementFromPoint at its location returns the rail's own icon).
So this is purely that the rail/panel/icon sizing (--rail-width: 52px, --panel-width: 340px in src/ui/tokens.css, plus the .rail-btn 36px targets in layout.css) is fixed in CSS pixels. On a small physical panel with very high pixel density, fixed-px chrome ends up physically tiny even though it computes "correctly" - the same issue most non-scaling web content has on this class of display.
Not urgent - Chrome's per-site zoom persists per-domain, so it's a one-time workaround per browser profile. Filing as a low-priority enhancement: consider sizing the rail/panel/icons with clamp() or a viewport-relative unit so they scale a bit on very high-density displays, or note the zoom workaround somewhere for anyone else who hits it.
(No screenshot attached - couldn't upload a binary image through this CLI session; happy to add one if it'd help, just ask.)
On a high-PPI, small-diagonal panel (reported case: 3840x2160 laptop screen, Chrome/Windows, OS display scaling at 100%), the rail (left icon strip) and surrounding chrome render so small at 100% browser zoom that they're hard to see or click. Zooming the browser to ~175% makes it usable.
Confirmed this isn't a layout/functional bug: reproduced with
vite --mode mockin headless Chrome at the same 3840x2160 viewport and inspected computed styles..railcomes out to exactly the CSS-defined52pxwidth (--rail-widthinsrc/ui/tokens.css), correctly positioned, not covered by anything (elementFromPointat its location returns the rail's own icon).So this is purely that the rail/panel/icon sizing (
--rail-width: 52px,--panel-width: 340pxinsrc/ui/tokens.css, plus the.rail-btn36px targets inlayout.css) is fixed in CSS pixels. On a small physical panel with very high pixel density, fixed-px chrome ends up physically tiny even though it computes "correctly" - the same issue most non-scaling web content has on this class of display.Not urgent - Chrome's per-site zoom persists per-domain, so it's a one-time workaround per browser profile. Filing as a low-priority enhancement: consider sizing the rail/panel/icons with
clamp()or a viewport-relative unit so they scale a bit on very high-density displays, or note the zoom workaround somewhere for anyone else who hits it.(No screenshot attached - couldn't upload a binary image through this CLI session; happy to add one if it'd help, just ask.)