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
The effort #245 and #255 both deferred and neither ticketed. #245 put it in Out of Scope as "the collapse styling — blur, compact title, the coupled height/padding constants as a shared primitive … it is one effort, and it is still fog on the map"; #255 shipped "the collapse decision, not the collapse look". This is that look, and it turns out to constrain screens rather than only decorate the bar.
The design's header is invisible at rest, and the tab's own large title carries the screen (prototype/screens.jsx:655):
At the top it's invisible (the tab's large title carries the screen). On scroll it blends in — a blurred, tinted bar with a bottom hairline — and the compact screen title slides in on the left, mirroring the large title that has just scrolled away.
The app's is always visible, and collapsing drops only the eyebrow (lib/app/app_header.dart, _Heading): at rest it draws YOUR DECK over Collection at headlineSmall; scrolled, it draws Collection alone. So the two run opposite ways round — the design gains a title on scroll, the app loses an eyebrow.
The design's chrome for the scrolled state is StickyHeaderChrome at height 116, with HeaderCompactTitle sliding in; neither has an app counterpart.
Why it is not only a bar
A screen cannot carry its own large title while the bar draws one at rest. The design pairs the two — invisible bar, large title on the screen — and the app has only the second half of the pair missing and the first half always on.
That already cost something. CardsTab opens with an <h1>Collection</h1> at the display step (screens.jsx:1629); the app's Cards screen cannot render it without saying "Collection" twice under the header's own, so #396 dropped it and shipped the count line alone. That is the right call while the bar behaves this way and the wrong shape once it does not — and the same trade is waiting on every other tab root.
The tab header — the at-rest transparency, the blurred and tinted scrolled state, the compact title's slide, the coupled height and padding.
The sub-screen bars.#245's other Out of Scope bullet: "Pushed pages keep their own AppBar for now; unifying them into the design's SubHeader shape is the same effort as the collapse styling." Whoever takes this should rule on whether both land together or the SubHeader half is split out — and register the answer, rather than letting the second half go quiet the way this one did.
Acceptance criteria
The tab header is transparent at rest and the tab's own large title carries the screen; on scroll it blends to the design's tinted, hairlined bar with the compact title — HeaderChrome + HeaderCompactTitle, asserted in test/widget/header_chrome_test.dart and test/widget/app_header_test.dart
Each tab root renders its own large title, and none says it twice — the Cards tab regains the one Design parity 10: the Cards grid hides the unearned remainder #396 dropped. test/widget/app_shell_navigation_test.dart walks the four tabs and asserts findsOneWidget against the bar's silence
The transition respects reduced motion, and the collapse state per branch that Each tab's header collapses as that tab scrolls #255 built still holds — ScrolledProgress carries the rule once, _collapsedByBranch is untouched, both covered by tests
dart format, flutter analyze, the metrics gate and the full suite (2563) clean, with a changelog bullet
Resolution
Shipped in PR #514 (4e26d41). The bar floats over the tab and is invisible at rest; HeaderChrome is the design's StickyHeaderChrome and takes its height from the caller, so #513 composes it rather than re-deriving it.
Three things the ticket did not foresee. AppOverlay grew the saturate(1.3) the design writes beside its blur, and an at(progress) that scales the whole token, so a bar fading in cannot bring the tint and snap the blur on behind it. 0.18em left OffTokens for AppTracking.chrome — the tab label was the one component set at it until the compact eyebrow turned out to be too. And FloatTopbar, which landed on main mid-branch, was filling with an opaque page and no blur where the design writes it with the header's own two constants; it takes mood.headerFill now.
One divergence, deliberately. The bar floats, so nothing lays the title and the entries out against each other — and the design never has to solve that, because it freezes Learn's date to Friday, May 8. Measured in Fraunces at the display rung, the widest date longDate can make sets 350.5pt where the entries begin 269pt into the title, so at the design's 24 an ordinary Wednesday loses its tail behind the two buttons. Narrowing the title would make that same date wrap, which the owner ruled out. Learn and Profile therefore take Path's own paddingTop: 64 — the design's answer to exactly this — and Cards keeps 24. Registered as OffTokens.tabTitleClearOfEntries with the measurement, and pinned by a test.
Checked before filing
Not owned: #226, #245, #254 and #255 are the header's history and all four are closed, with #245 and #255 deferring this explicitly. Not in flight: PR #440 touches app_header.dart only to wrap the action buttons in a Tour stop. Not already fixed: _Heading on main still draws the title at rest.
The effort #245 and #255 both deferred and neither ticketed. #245 put it in Out of Scope as "the collapse styling — blur, compact title, the coupled height/padding constants as a shared primitive … it is one effort, and it is still fog on the map"; #255 shipped "the collapse decision, not the collapse look". This is that look, and it turns out to constrain screens rather than only decorate the bar.
Surfaced building #396, where it forced a call.
The two behaviours
The design's header is invisible at rest, and the tab's own large title carries the screen (
prototype/screens.jsx:655):The app's is always visible, and collapsing drops only the eyebrow (
lib/app/app_header.dart,_Heading): at rest it drawsYOUR DECKoverCollectionatheadlineSmall; scrolled, it drawsCollectionalone. So the two run opposite ways round — the design gains a title on scroll, the app loses an eyebrow.The design's chrome for the scrolled state is
StickyHeaderChromeat height 116, withHeaderCompactTitlesliding in; neither has an app counterpart.Why it is not only a bar
A screen cannot carry its own large title while the bar draws one at rest. The design pairs the two — invisible bar, large title on the screen — and the app has only the second half of the pair missing and the first half always on.
That already cost something.
CardsTabopens with an<h1>Collection</h1>at the display step (screens.jsx:1629); the app's Cards screen cannot render it without saying "Collection" twice under the header's own, so #396 dropped it and shipped the count line alone. That is the right call while the bar behaves this way and the wrong shape once it does not — and the same trade is waiting on every other tab root.Two halves, and #245 says they are one effort
The tab header — the at-rest transparency, the blurred and tinted scrolled state, the compact title's slide, the coupled height and padding.
The sub-screen bars. #245's other Out of Scope bullet: "Pushed pages keep their own
AppBarfor now; unifying them into the design'sSubHeadershape is the same effort as the collapse styling." Whoever takes this should rule on whether both land together or theSubHeaderhalf is split out — and register the answer, rather than letting the second half go quiet the way this one did.Acceptance criteria
HeaderChrome+HeaderCompactTitle, asserted intest/widget/header_chrome_test.dartandtest/widget/app_header_test.darttest/widget/app_shell_navigation_test.dartwalks the four tabs and assertsfindsOneWidgetagainst the bar's silenceScrolledProgresscarries the rule once,_collapsedByBranchis untouched, both covered by testsSubHeaderhalf is split out as Pages opened from a tab wear a stock Material bar, not the design's #513, with the reason recorded theredart format,flutter analyze, the metrics gate and the full suite (2563) clean, with a changelog bulletResolution
Shipped in PR #514 (
4e26d41). The bar floats over the tab and is invisible at rest;HeaderChromeis the design'sStickyHeaderChromeand takes its height from the caller, so #513 composes it rather than re-deriving it.Three things the ticket did not foresee.
AppOverlaygrew thesaturate(1.3)the design writes beside its blur, and anat(progress)that scales the whole token, so a bar fading in cannot bring the tint and snap the blur on behind it. 0.18em leftOffTokensforAppTracking.chrome— the tab label was the one component set at it until the compact eyebrow turned out to be too. AndFloatTopbar, which landed onmainmid-branch, was filling with an opaque page and no blur where the design writes it with the header's own two constants; it takesmood.headerFillnow.One divergence, deliberately. The bar floats, so nothing lays the title and the entries out against each other — and the design never has to solve that, because it freezes Learn's date to
Friday, May 8. Measured in Fraunces at the display rung, the widest datelongDatecan make sets 350.5pt where the entries begin 269pt into the title, so at the design's 24 an ordinary Wednesday loses its tail behind the two buttons. Narrowing the title would make that same date wrap, which the owner ruled out. Learn and Profile therefore take Path's ownpaddingTop: 64— the design's answer to exactly this — and Cards keeps 24. Registered asOffTokens.tabTitleClearOfEntrieswith the measurement, and pinned by a test.Checked before filing
Not owned: #226, #245, #254 and #255 are the header's history and all four are closed, with #245 and #255 deferring this explicitly. Not in flight: PR #440 touches
app_header.dartonly to wrap the action buttons in a Tour stop. Not already fixed:_Headingonmainstill draws the title at rest.