Proposal: floating chrome — what is left after the sidebar plate

[Astro-Han]

Problem

Maka's desktop shell reads flat next to comparable Mac chat apps. feat/theme-elevation-floating-shadow took a first pass — the sidebar is a floating plate on one continuous backplate, the session title is a centred capsule, the top-right session controls are raised onto the plate tier, and the sidebar's search/collapse pair ends at that plate's inner edge.

Comparing that state against Meta AI's Mac app frame by frame shows the remaining gap is not polish on what we have. What produces the float there is a mechanism we do not use at all.

Sources: Meta's published product still (3024×1964) and a 24.8s screen recording at the same resolution, sampled at seven points. Maka: the Product/Shell Official AppShell stories, with the page pinned to height: 100vh at screenshot time so the story reflects the real window instead of growing to the transcript's height.

Measured

1. Meta's floating chrome is translucent, and the transcript scrolls underneath it. In the recording, body text is plainly visible and blurred through the composer and through the title capsule — mid-sentence, mid-paragraph. The float does not come from the shadow. It comes from being able to see what the surface covers.

Ours is opaque and nothing can pass under it:

• The composer plate computes to background: oklch(1 0 0), backdrop-filter: none.
• .mainColumn carries padding-top: var(--maka-plate-titlebar-clearance), so the transcript starts below the title capsule and can never reach it. The capsule floats over an empty band, not over content.

Astryx already ships most of what is needed on the composer side: ChatLayout renders a sticky dock with a backdrop-filter: blur(12px) layer, 100px tall, gradient-masked. We render it today and it is invisible, because the composer above it is opaque and the 100px band behind it is flat backplate — blurring a solid colour produces a solid colour.

2. Surface hierarchy is inverted. Mean RGB over flat regions:

	sidebar	content / backplate	delta
Meta AI	(237, 241, 244)	(250, 250, 252)	13/255 — sidebar darker, and cooler
Maka, this branch	(247, 247, 247)	(243, 243, 243)	4/255 — sidebar lighter

Meta's content region is the brightest surface in the window and its sidebar recedes behind it; the cool cast is macOS vibrancy sampling the desktop through it. Its sidebar is not inset at all — it meets the window's top, left and bottom edges with no gutter and no corner radius of its own.

Correcting an earlier claim made in this line of work: these two surfaces were previously reported as within ~1/255 of each other. That reading came from a compressed video frame and was wrong.

3. Meta's content layer is entirely flat. Its structured results — a five-item list of accounts with thumbnails — are outlined cards with no fill and no shadow. Nothing in the transcript is raised. Elevation there is strictly a property of chrome.

4. There are no tool-call rows in 25 seconds of Meta's recording. A single collapsed "Show thinking" row is the entire process surface. Our transcript carries a stack of tool rows, and they run the full content width while prose is capped at --maka-chat-measure: 680px. Our content layer is heavier than theirs by a wide margin, which is a product difference rather than a defect, but it changes what raising the chrome will look like against it.

5. Meta's message actions are always visible — bare glyphs under the text, no container, no hover gate.

Decisions needed

These are the reason this is an issue and not a branch. Each one changes what the follow-up PRs are.

D1. Does the transcript scroll under the chrome? This is the whole mechanism from finding 1. On the composer side it is nearly free — make the composer surface translucent and Astryx's dock does the rest. On the title side it means moving .mainColumn's top padding into the scrolled content so the scroll container reaches the window top. The cost is real: the top 36px is -webkit-app-region: drag, so text scrolled under it cannot be selected and anything in it cannot be clicked. Either the drag region shrinks to what is left of the strip, or content stays out from under the title and only the composer gets this.

D2. How is a translucent surface expressed across eleven palettes? Ours must follow data-maka-theme in both modes; a fixed white at fixed alpha will not. Relative (oklch(from var(--background) l c h / <a>)) follows the palette, but the same alpha does not read the same on a dark backplate as on a light one. Needs one rule stated once, not per-surface values.

D3. Do we follow Meta's inverted hierarchy — content brightest, sidebar receding? Their sidebar's cool recession is vibrancy, which samples the user's desktop and cannot express a palette. Answering D1 and D2 does not require answering this, but item 5 below should not be tuned before it is settled.

D4. Does the content layer stay flat? Meta's answer is unambiguous. If our transcript cards, tool rows and attachment tray start carrying fills and shadows too, the chrome stops reading as a separate tier and the whole exercise cancels out. Worth stating as a rule now, while there is little to undo.

D5. Does everything in the transcript share one reading column? Prose is capped at 680px; tool rows are not, and run the full width. Meta puts prose and structured results in the same column.

D6. Where does new-conversation live? Meta floats it as a button on the content plate at the top-left, overlapping the sidebar's edge — the strongest single floating element in the window. Ours is the first row of the sidebar list, with a ⌘N hint. Moving it is an information-architecture change, not a paint change.

D7. Are message actions always visible? Ours are hover-gated; Meta's are not.

Where I lean

Stated so there is something to argue with, not to close the questions.

• D1 — yes, both surfaces. The composer side is nearly free. On the title side, shrink the drag region to the sidebar's top strip and the capsule itself rather than keeping the full 36px band. Meta has no conventional titlebar strip at all; its traffic lights sit on the sidebar.
• D2 — relative, with the alpha in light-dark(). One rule for every floating surface, not a value per surface.
• D3 — no. Their recession is vibrancy, which samples the desktop and cannot express a palette, and the palettes are a product feature.
• D4 — flat, stated as a rule now. Our content layer is already far heavier than theirs. If it starts to lift, the chrome tier cancels out.
• D5 — one column. Prose at 680px beside full-width tool rows is two reading widths in one transcript.
• D6 — move it, and do it last. It is an IA change and should not ride along with paint changes.
• D7 — always visible. Small, and independent of everything above.

Work, once the above are settled

Grouped by what one revert should undo, so each group is one PR.

1. Translucent chrome + scroll-under (D1, D2). The composer surface, the title capsule, and the top-right cluster.
2. New-conversation affordance on the content plate (D6).

3. Top-right action cluster (D3 does not block this). Meta groups its top-right icon buttons inside one pill container with its own shadow; we show a single 记忆 token in a session and nothing at all on a new task. Needs a container component, not a style rule.
4. Composer control treatment. Every control in Meta's composer footer is a discrete object: outlined circles, an outlined pill for the model selector, a filled circle for the mic, a gradient circle for send. Ours are bare glyphs and text.

5. Shadow weight. Our --shadow-low far layer (0 6px 30px / 7%) is heavier than Meta's. Judge it after 1–3, when there is more than one floating object to judge it against, and after D3.
6. Sidebar identity (D3). Meta opens its sidebar with a product mark and closes it with an avatar row; ours opens with the list and closes with a 设置 text row.

Already matching, and not in scope: search/collapse as bare glyphs at the sidebar's top-right, the centred title capsule's placement, and sidebar width as a share of window width (Meta ≈26%, ours ≈23%).

The first pass will be opened as its own PR shortly. This discussion is an inventory and a request for decisions, not a claim on the follow-ups.

---

Generated with Claude Code. The measurements above were produced by scripted sampling of the two sources and by reading computed styles in a live render; the comparison, the grouping and the open questions are AI-drafted. The contributor of record reviews this before any of it is acted on.

---

中文对照

问题

Maka 的桌面外壳和同类 Mac 聊天应用比起来是平的。feat/theme-elevation-floating-shadow 已经做了第一轮：侧栏成为浮在单一底板上的板块，会话标题变成居中胶囊，右上角的会话控件抬到板层，侧栏的搜索/折叠按钮收到板块内边缘。

逐帧对比 Meta AI 的 Mac 应用之后，剩下的差距不是把现有的东西调好看。产生漂浮感的那个机制，我们根本没有用。

素材：Meta 公开的产品图（3024×1964）和同分辨率的 24.8 秒录屏，取了七帧。Maka：Product/Shell Official AppShell 系列 story，截图时把页面钉在 height: 100vh，让 story 反映真实窗口，而不是被 transcript 撑高。

测量

1. Meta 的浮起 chrome 是半透明的，transcript 从它底下滚过去。 录屏里，正文清清楚楚地从 composer 和标题胶囊底下透出来并被模糊 —— 在句子中间、段落中间。漂浮感不来自阴影，来自你能看见它盖住了什么。

我们的是不透明的，也没有任何东西能从底下经过：

• composer 面板计算值为 background: oklch(1 0 0)、backdrop-filter: none。
• .mainColumn 带着 padding-top: var(--maka-plate-titlebar-clearance)，transcript 从标题胶囊下方才开始，永远够不到它。胶囊浮在一条空带上，不是浮在内容上。

composer 这一侧 Astryx 其实已经给足了：ChatLayout 渲染一个 sticky dock，带 backdrop-filter: blur(12px)、高 100px、渐变遮罩。我们今天就在渲染它，而它看不出效果，因为上面的 composer 不透明，而它背后那 100px 是纯色底板 —— 模糊一块纯色还是那块纯色。

2. 表面层级是反的。 平坦区域的 RGB 均值：

	侧栏	内容 / 底板	差
Meta AI	(237, 241, 244)	(250, 250, 252)	13/255，侧栏更暗、更冷
Maka，本分支	(247, 247, 247)	(243, 243, 243)	4/255，侧栏更亮

Meta 的内容区是整个窗口最亮的面，侧栏退到它后面；冷色调是 macOS vibrancy 透过它采样桌面。它的侧栏完全没有内缩 —— 顶到窗口的上、左、下三边，没有留白，也没有自己的圆角。

更正此前在这条线上的说法：这两个面之前被报告为相差约 1/255。那次读数来自压缩过的视频帧，是错的。

3. Meta 的内容层完全是平的。 它的结构化结果 —— 五个带缩略图的账号卡片 —— 只有描边，没有填充、没有阴影。transcript 里没有任何东西被抬起。在那里，抬升严格只属于 chrome。

4. 25 秒录屏里没有任何工具调用行。 一个折叠的 "Show thinking" 就是全部的过程呈现。我们的 transcript 有一整叠工具行，而且铺满整个内容宽度，正文却卡在 --maka-chat-measure: 680px。我们的内容层比它重得多，这是产品差异而不是缺陷，但它决定了把 chrome 抬起来之后，对着这样的内容看上去会是什么样。

5. Meta 的消息操作条常驻 —— 正文下方的裸图标，没有容器，也不靠 hover 触发。

需要拍板的问题

这是它作为一条 discussion 而不是一个分支的原因。每一条都会改变后续 PR 的形态。

D1. transcript 要不要滚到 chrome 底下？ 这就是发现 1 的全部机制。composer 一侧几乎不花成本 —— 把 composer 表面改成半透明，Astryx 的 dock 负责其余。标题一侧意味着把 .mainColumn 的上内边距移进被滚动的内容里，让滚动容器抵达窗口顶部。代价是真实的：顶部 36px 是 -webkit-app-region: drag，滚到那里的文字选不中，里面的东西点不了。要么拖拽区收缩到这条上剩下的部分，要么内容不进标题底下，只有 composer 享受这个待遇。

D2. 半透明表面在十一套 palette 上怎么表达？ 我们的必须跟随 data-maka-theme，且在两种模式下都成立；固定的白配固定的 alpha 做不到。相对写法（oklch(from var(--background) l c h / <a>)）能跟随 palette，但同一个 alpha 在深色底板和浅色底板上读起来不一样。需要一条只说一次的规则，而不是逐个表面给值。

D3. 要不要跟 Meta 反转层级 —— 内容最亮、侧栏后退？ 他们侧栏的冷色后退靠 vibrancy，而 vibrancy 采样用户桌面，表达不了 palette。回答 D1 和 D2 不需要先回答这一条，但下面第 5 项在它定下来之前不该调。

D4. 内容层保持平吗？ Meta 的答案毫不含糊。如果我们的 transcript 卡片、工具行和附件托盘也开始带上填充和阴影，chrome 就不再读作独立的一层，整件事互相抵消。趁着还没什么要撤销的，现在就把它定成规则。

D5. transcript 里的所有东西共用一个阅读列吗？ 正文卡在 680px，工具行没有，铺满整宽。Meta 把正文和结构化结果放在同一列里。

D6. 新建对话放在哪？ Meta 把它做成内容板左上角的浮起按钮，压在侧栏边缘上 —— 是窗口里最强的单个漂浮元素。我们的是侧栏列表第一行，带 ⌘N 提示。搬动它是信息架构改动，不是上色改动。

D7. 消息操作条常驻吗？ 我们的靠 hover，Meta 的不是。

我的倾向

写出来是为了有个能被反驳的东西，不是为了把问题关掉。

• D1 —— 两处都做。 composer 一侧几乎免费。标题一侧把拖拽区收缩到侧栏顶条和胶囊本身，而不是保留整条 36px。Meta 根本没有传统的标题栏条，红绿灯直接落在侧栏上。
• D2 —— 相对写法，alpha 本身放进 light-dark()。 所有浮起表面共用一条规则，而不是一个表面一个值。
• D3 —— 不跟。 他们的后退靠 vibrancy，而 vibrancy 采样桌面、表达不了 palette，而 palette 是产品功能。
• D4 —— 保持平，现在就定成规则。 我们的内容层本来就比他们重得多。它一旦开始抬升，chrome 这一层就白做了。
• D5 —— 一个列宽。 680px 的正文旁边是整宽的工具行，同一段 transcript 里两种阅读宽度。
• D6 —— 搬，而且放到最后。 它是信息架构改动，不该跟着上色改动一起走。
• D7 —— 常驻。 改动小，而且和上面所有事都不相干。

上面定了之后的工作

按"一次 revert 应该撤销什么"分组，每组一个 PR。

1. 半透明 chrome + 内容穿过（D1、D2）。composer 表面、标题胶囊、右上角控件组。
2. 内容板上的新建对话入口（D6）。
3. 右上角控件组（不被 D3 阻塞）。Meta 把右上角的图标按钮装进一个带自己阴影的胶囊容器；我们在会话里只显示一个 记忆 token，新任务态什么都没有。需要一个容器组件，不是一条样式规则。
4. composer 控件处理。 Meta 的 composer 底排每个控件都是独立物件：描边圆圈、模型选择器是描边胶囊、麦克风是实心圆、发送是渐变圆。我们的是裸图标和文字。
5. 阴影权重。 我们 --shadow-low 的远层（0 6px 30px / 7%）比 Meta 的重。等 1–3 落地、有不止一个浮起物可以对照之后再判断，并且要在 D3 之后。
6. 侧栏 identity（D3）。Meta 的侧栏以产品标记开头、以头像行结尾；我们以列表开头、以 设置 文字行结尾。

已经一致、不在范围内：侧栏右上角作为裸图标的搜索/折叠、居中标题胶囊的位置、侧栏宽度占窗口宽度的比例（Meta ≈26%，我们 ≈23%）。

第一轮会很快作为独立 PR 提出。这条 discussion 是一次盘点和一次决策请求，不是对后续工作的认领。

[chihumyum]

I suggest we don't go with floating plate(or island) design. Floating islands became widespread with macOS 26, but they don't really add value accessibility-wise.

Now even Apple is walking back the floating-sidebar treatment in macOS 27.

I think maybe we could try steering the app in a more pragmatic, clean, and performance-first direction. It feels like a better fit for the character and strengths of this harness.

I ain't no professional designer, just put a few thoughts out here.