/* ===================================================================== ROUND 30, JOB 30.7 -- search_row_v2_live ONE RULE DOES THE ALIGNMENT, ON BOTH PAGES. Reached only through `.lh-wrap.ttc-search-row-v2`, which app/listhead.py puts on the wrapper when `search_row_v2_live` is set. Both the search page and My Recipes are drawn by that one function, which is also why round 25's gate could pass while both pages were wrong: they were wrong identically, from the same string, and the gate compared them with each other. THE RULE, off the drawing 04-search-row-FINAL.jpg, whose two dashed guides are the band's own inset: THE ROW BELOW THE BAND INHERITS THE BAND'S HORIZONTAL PADDING. Everything else follows from it -- the first button's left edge lands on the S of "Search Results For:" the control's right edge lands on the white field's right edge the "nothing found" sentence lands on that same S 49px at >=1024, 22px at <=1023, 18px at <=600. NEVER HARD-CODED: the three numbers below are the BAND's, in one place, and the row reads them. ===================================================================== */ /* ===================================================================== ROUND 88 -- THE FACE THIS FILE ASKS FOR, SERVED BY THIS FILE. THE FAULT, MEASURED, NOT GUESSED. Every rule below that sizes the three search tabs and the "Organized by" control names `Poppins`. The site's ONLY @font-face rules for Poppins live in static/site/cards-v2.css -- round 32 put them there, beside the card that needed them -- and the search page asks for that stylesheet from `card_list()`, i.e. ONLY WHEN THE RESULT LIST IS NOT EMPTY. So the controls' typeface depended on whether the search happened to find anything: /?s=chicken cards-v2.css loaded -> painted Poppins /?s=carbonara&st=news no results, no cards-v2.css -> painted the browser's default sans (DejaVu Sans on Linux, Times/Arial elsewhere) Both measured with CSS.getPlatformFontsForNode -- the PAINTED face, not `getComputedStyle().fontFamily`, and with this build machine's own installed Poppins hidden by FONTCONFIG_FILE. See tools/font_probe_88.py, and the warning at the top of cards-v2.css that explains why both precautions are necessary: headless Chromium here resolves Poppins from the system and will otherwise report a face the visitor never receives. THE FIX IS THE FACE, NOT THE FAMILY. My Recipes' "Organized by" -- the reference Tom named -- is Poppins and stays Poppins; this file is simply no longer allowed to name a face it does not serve. The four declarations are the SAME FAMILY, WEIGHTS AND URLS as the ones in cards-v2.css, so a page carrying both stylesheets downloads each .woff2 exactly once and no page gains a single request. tests/test_font_faces_88.py asserts the two copies stay byte-identical so they cannot drift. Poppins is SIL Open Font License 1.1 and the licence travels with the font: static/site/fonts/OFL.txt, served at /site/fonts/OFL.txt. Poppins (c) 2020 The Poppins Project Authors, Reserved Font Name "Poppins". ===================================================================== */ @font-face { font-family: Poppins; font-style: normal; font-weight: 400; font-display: swap; src: url("/site/fonts/poppins-400.woff2") format("woff2"); } @font-face { font-family: Poppins; font-style: normal; font-weight: 500; font-display: swap; src: url("/site/fonts/poppins-500.woff2") format("woff2"); } @font-face { font-family: Poppins; font-style: normal; font-weight: 600; font-display: swap; src: url("/site/fonts/poppins-600.woff2") format("woff2"); } @font-face { font-family: Poppins; font-style: normal; font-weight: 700; font-display: swap; src: url("/site/fonts/poppins-700.woff2") format("woff2"); } /* AND A REAL FALLBACK BEHIND IT. `font: 400 16px Poppins` names one family and nothing else, so the day the face is missing the browser does not fall back to the site's own typeface -- it falls back to its default, which is what made an empty tab read as DejaVu Sans rather than as Montserrat. The stack below is listhead.css's own `body` stack, so the worst case is now the font the rest of the page is already set in. Nothing else about these rules moves: same weights, same sizes, same line-heights, same colours. */ .lh-wrap.ttc-search-row-v2 { --band-pad: 49px; } @media (max-width: 1023px) { .lh-wrap.ttc-search-row-v2 { --band-pad: 22px; } } @media (max-width: 600px) { .lh-wrap.ttc-search-row-v2 { --band-pad: 18px; } } .lh-wrap.ttc-search-row-v2 > .lh-tools, .lh-wrap.ttc-search-row-v2 > .lh-empty { padding-left: var(--band-pad); padding-right: var(--band-pad); } /* FAULT 10 (round 30) SET THIS TO 30px, ROUND 76 PHASE 1 MADE IT 3px, AND ROUND 76b MAKES IT 0 -- THE BAND AND THE FILTER TOUCH. THE HISTORY, because this one number has now moved three times and the point of writing it down is that it stops moving. round 30 30px. The locked 30px spacing rule read as the gap under the band, and applied to all three pages this class reaches. Measured before round 76: band bottom 474.7, row top 504.7 at 1440; 499.9 / 529.9 at 390 -- 30px of page BACKGROUND running through a component that is drawn as one piece. round 76 3px, from the handover file's GEOMETRY comment ("3px under it") and its own `.lh-tools{margin-top:3px}`. round 76b 0. Tom's brief on the round-76 candidate: the maroon band, the Filter and "Organized by" are ONE element and must READ as one -- "Band -> Filter vertical gap = 0 (they touch, one unified component)". 3px still draws a hairline of page background across the seam, and at 3px the join is a near miss rather than a join. 0 is the number in the brief and it is not a number invented here. THE 30px SPACING RULE IS UNTOUCHED AND STILL VALID EVERYWHERE ELSE. It is the gap BELOW the whole component, which `.lh-wrap{margin-bottom:30px}` in listhead-page.css holds, and which no rule in this round goes near. This spot is one element, not two things that need spacing between them. `.lh-filter` is drawn with square TOP corners and 30px bottom ones (listhead.css:33) precisely so it reads as pulled out from under the band; `.lh-band` is `position:relative; z-index:2`, so it paints over the seam and the two meet with no line between them. */ .lh-wrap.ttc-search-row-v2 > .lh-tools { margin-top: 0; align-items: stretch; } .lh-wrap.ttc-search-row-v2 > .lh-empty { margin-top: 26px; font: 400 17px Poppins, Montserrat, "Segoe UI", system-ui, Arial, sans-serif; color: #4e5155; } /* ---- THE BUTTONS ------------------------------------------------------- FAULT 2: flex-grow:1 stretched them to fill 65.22% of the row. The drawing sizes each to its own words. FAULT 3: 52px tall, centred in a 60px container by align-items:flex-end, so they sat 4px high. 64px, so they share the control's top and bottom. FAULT 1 WAS ALREADY FIXED, and saying so is the point of measuring before building. The round's brief describes listhead.css's @media (min-width:787px) block as making .simple-btn a flex container without `justify-content`, so every label falls left above 787px. MEASURED with this switch OFF: at 1440 the computed justify-content is already `center` and the label is 0.0px off centre. listhead.css:385 carries `.lh-tools--tabs #subpages-menu nav .simple-btn { justify-content: center }` in its own @media (min-width:787px) block -- an earlier round closed it. The declaration below is kept because this file has to hold the whole rule for the buttons it restyles, and because it now applies BELOW 787 too, where the buttons were `display:block` and only centred by `text-align`. FAULT 8: `gap:10px` and a per-button `margin:.4rem` fought below 1000px. The margin goes; the gap stays. */ .lh-wrap.ttc-search-row-v2 .lh-tools--tabs #subpages-menu { flex: 0 0 auto; margin: 0; } .lh-wrap.ttc-search-row-v2 .lh-tools--tabs #subpages-menu nav { display: flex; gap: 10px; flex-wrap: wrap; } .lh-wrap.ttc-search-row-v2 .lh-tools--tabs #subpages-menu nav .simple-btn, .lh-wrap.ttc-search-row-v2 .lh-tools .simple-btn { flex: 0 0 auto; min-width: 0; margin: 0; padding: 14px 26px; min-height: 64px; display: inline-flex; align-items: center; justify-content: center; border-radius: 14px; font: 400 16px/1 Poppins, Montserrat, "Segoe UI", system-ui, Arial, sans-serif; letter-spacing: -.01em; white-space: nowrap; } /* THE SPACE BEFORE THE COUNT, in CSS and not in the markup -- "Recipes (27)", the count bold and the word regular. */ .lh-wrap.ttc-search-row-v2 .lh-tools .simple-btn strong { font-weight: 700; margin-left: .34em; } /* ---- THE "ORGANIZED BY" CONTROL --------------------------------------- FAULT 6: "Best match" truncated -- `overflow:hidden;text-overflow:ellipsis` on a control too narrow to hold its own words. FAULT 9: it got WIDER as the window narrowed -- 150px at 1244, 185px at 1100 -- because `flex: 0 0 17.43%` is a percentage of a shrinking row. Both go: 230px minimum, sized to its content, never clipped. FAULT 5 WAS ALSO ALREADY FIXED: listhead.css:390 carries `.lh-tools--tabs .lh-sort b { color: var(--dark) }`. Measured black only in the base rule at listhead.css:63, which that one overrides on the search page but not on My Recipes, whose row has no `.lh-tools--tabs`. So #2b2b2b below is doing real work on ONE of the two pages, not both. */ .lh-wrap.ttc-search-row-v2 .lh-sort { margin-left: auto; margin-right: 0; /* the padding above does this now */ flex: 0 0 auto; min-width: 230px; width: auto; min-height: 64px; height: auto; border-radius: 24px; padding: 12px 28px; background: var(--cream, #fffeec); border: 1px solid #d3d2cb; display: grid; grid-template-columns: 1fr auto; grid-template-areas: "label chev" "value chev"; align-items: center; column-gap: 14px; position: relative; cursor: pointer; } .lh-wrap.ttc-search-row-v2 .lh-sort small { grid-area: label; font: 400 12px/1.25 Poppins, Montserrat, "Segoe UI", system-ui, Arial, sans-serif; color: #8a887c; white-space: nowrap; } .lh-wrap.ttc-search-row-v2 .lh-sort b { grid-area: value; font: 700 15px/1.3 Poppins, Montserrat, "Segoe UI", system-ui, Arial, sans-serif; color: #2b2b2b; /* --ink, not #000 */ margin-top: 3px; white-space: nowrap; overflow: visible; text-overflow: clip; /* FAULT 6: never clip its words */ } .lh-wrap.ttc-search-row-v2 .lh-sort .chev { grid-area: chev; position: static; margin: 0; align-self: center; } /* FAULT 7: the dropdown opened on :hover / :focus-within only, so a phone could never open it -- there is no hover on a touch screen and the div was not focusable. `listhead.js` adds `.open` on tap; this is the rule that makes `.open` mean something, and the hover path is kept for a mouse. */ .lh-wrap.ttc-search-row-v2 .lh-sort.open > .lh-sortmenu { display: block; } .lh-wrap.ttc-search-row-v2 .lh-sort { touch-action: manipulation; } /* Below 1023 the row stacks; the padding rule above still holds it to the band's own inset, which is the point. */ @media (max-width: 786px) { /* ROUND 76b: 10px, which is listhead.css's own number -- see the QUEUE 75 block below, where the 14 was introduced. */ .lh-wrap.ttc-search-row-v2 > .lh-tools { flex-wrap: wrap; gap: 10px; } .lh-wrap.ttc-search-row-v2 .lh-sort { margin-left: 0; } } /* ---- MY RECIPES: THE SAME TREATMENT, AND WHERE IT DIFFERS --------------- The two pages are drawn by the same function but not with the same elements: the search page puts TYPE BUTTONS in this row, and My Recipes puts a "Filter" dropdown there instead. Measured on My Recipes at 1440 before this block: .lh-tools content box starts at 127.72 (78.72 + the band's 49px) the h1's S is at 127.72 -- so the ROW is already right .lh-filter's own box starts at 149.78 -- 22.06px further in, because listhead.css gives it its own padding-left:22px .lh-filter is 60px tall against the control's 64 -- the 4px the gate reported as a bottom-edge mismatch So the rule "the first control's left edge sits on the S" needs the filter's own inset removed, not the row's changed. Its label keeps its left alignment and its chevron keeps the right: it is a dropdown, like the "Organized by" control beside it, and neither is a centred tab. */ .lh-wrap.ttc-search-row-v2 .lh-tools > .lh-filter { padding-left: 0; margin-left: 0; min-height: 64px; display: inline-flex; align-items: center; } /* ===================================================================== QUEUE 75, PHASE 2: BELOW 787 THE TWO CONTROLS ARE ONE ATTACHED ROW, AND "Organized by" IS CENTRED UNDER "Filter". listhead.css stacks this row and CENTRES it below 787 (`flex-direction:column; align-items:center`). This file used to answer with `align-items:stretch`, so the centring never happened -- that one declaration is the override the brief names. Measured on the candidate before this change, at a 390px phone, on the category pages and the hub: .lh-filter l= 38.0 r=304.0 w=266.0 .lh-sort l= 38.0 r=352.0 w=314.0 -- two controls of different widths, sharing a left edge and parting company 48px short on the right. That is the "detached and not centred" in the brief: nothing lines up with anything, and neither box is centred in the row. THE TWO EDGES THAT MATTER STILL DO. Round 30's rule -- the row inherits the band's own horizontal padding -- is held by `.lh-tools`' padding, which is untouched; it is the CONTROLS inside that are now arranged to it. `.lh-filter` fills the row, so its two edges land on the band's inset on both sides (it was `calc(100% - 48px)` from listhead.css, which is what pulled its right edge 48px in). "Organized by" then sizes to its own words and centres UNDER the Filter, which is what the brief asks for and what `align-items:center` in listhead.css was always trying to do. THE SEARCH PAGE'S BUTTONS DO NOT MOVE. Its `#subpages-menu` keeps the row's full width (`align-self:stretch`), so the first button's left edge stays on the S of "Search Results For:" -- round 30's other rule, and measured unchanged after this block. ===================================================================== */ @media (max-width: 786px) { .lh-wrap.ttc-search-row-v2 > .lh-tools { flex-direction: column; align-items: center; /* was `stretch`, which cancelled listhead.css */ /* ROUND 76b: 10px, NOT 14. This is the "small internal gap" in Tom's brief -- "the 'Organized by' control is part of the same element, with a small internal gap of ~10px (tighter than the standard 30px)" -- and it is not a new number either: listhead.css:103, lifted byte for byte out of design/recipe-list-header-v8.html, is `@media(max-width:786px){.lh-tools{...;gap:10px;...}}`. Queue 75 phase 2 wrote 14 here while it was fixing the column direction, and 14 beat the file's 10 on specificity -- measured at 390 before this round: filter bottom 542.9, sort top 556.9, a 14.0px gap. That is the drift the brief calls reinvented spacing, and 10 is the restore. */ gap: 10px; } .lh-wrap.ttc-search-row-v2 .lh-tools > .lh-filter { width: 100%; /* listhead.css: calc(100% - 64px) / (- 48px) */ margin: 0; } .lh-wrap.ttc-search-row-v2 .lh-sort { margin: 0 auto; /* centred under the Filter */ width: auto; min-width: 230px; /* its words are never clipped -- fault 6 */ max-width: 100%; } .lh-wrap.ttc-search-row-v2 .lh-tools--tabs #subpages-menu { align-self: stretch; } } /* ===================================================================== QUEUE 75, PHASE 2: THE OPEN PANEL SITS ON THE CONTROL IT REPLACES. `.lh-panel` is the Filter's open state: listhead.css hides `.lh-filter` and draws the panel in its place, with the same cream, the same shadow and the same `border-radius:0 0 30px 30px`. But its box is the ORIGINAL percentages -- `left:2.57%; width:65.22%` of `.lh-wrap` -- while the control it replaces has been on the band's inset since round 30. So the flap jumped sideways the moment a reader opened it. Measured before: 1440 filter 127.7 .. 687.6 panel 103.3 .. 727.1 (-24.4/+39.5) 390 filter 38.0 .. 304.0 panel 44.0 .. 346.0 ( +6.0/+42.0) The panel now takes the SAME two edges as the Filter: the band's inset on the left, and 65.22% of the row's inner width -- the `flex:0 0 65.22%` the control itself is given -- for its width. Below 787, where the Filter fills the row, so does the panel. ===================================================================== */ .lh-wrap.ttc-search-row-v2 > .lh-panel { left: var(--band-pad); width: calc((100% - var(--band-pad) * 2) * 0.6522); } @media (max-width: 786px) { .lh-wrap.ttc-search-row-v2 > .lh-panel { width: calc(100% - var(--band-pad) * 2); } } /* ===================================================================== ROUND 76, PHASE 1: THE ROW IS ATTACHED TO THE BAND, AND ON A PHONE THE FILTER IS THE HEIGHT THE HANDOVER FILE SPECIFIES. WHAT THE DOCUMENTATION SAYS, and it is the only number in it: design/recipe-list-header-v8.html, the GEOMETRY comment -- "filter 65.22% of the band, inset 2.57% from its left, 3px under it, square top corners, 30 bottom corners, soft shadow, 60 tall" "AT 786 AND BELOW: sort drops UNDER the filter; filter shrinks 60 -> 40 and keeps an equal inset both sides; sort centred" "OPEN PANEL: pulled out from under the band - square top corners, 3px below it, same width and inset as the filter bar" and its own rules: `.lh-tools{margin-top:3px}`, `.lh-filter{height:60px}`, `@media(max-width:786px){.lh-filter{height:40px}}`, `.lh-sort{height:51px}`. static/site/listhead-page.css says the same in words: "the file puts the filter 3px under the band on purpose, and that 3 is inside the component, not the gap below it". So the documented mobile height is 40px against 60px on the desktop -- 66.7%, which is the "~60%" the round asks for, and it is a number Tom already wrote down rather than one invented here. This file had overridden it to 64px everywhere (`min-height: 64px`, round 30, so the Filter shared a top and a bottom edge with the search page's 64px buttons); at 390 that is 60% TALLER than the file, not 40% shorter. MEASURED AT 390 BEFORE: filter h=64, sort h=64, both 30px below the band. AFTER: filter h=40, sort h=51, the filter's top edge 3px under the band. The desktop is untouched at 64/64 -- round 30's edge-sharing rule is a desktop rule and every measurement behind it was taken at 1440. ===================================================================== */ @media (max-width: 786px) { .lh-wrap.ttc-search-row-v2 .lh-tools > .lh-filter { min-height: 40px; /* was 64px, from the block above */ height: 40px; /* v8: "filter shrinks 60 -> 40" */ } .lh-wrap.ttc-search-row-v2 .lh-sort { min-height: 51px; /* v8: `.lh-sort{height:51px}` */ padding: 9px 23px; /* v8's own padding, not the 12/28 above */ } } /* THE OPEN PANEL TAKES THE SAME TWO THINGS: the band's edge, and the phone's reduced height. The panel is `position:absolute; top:0` inside `.lh-wrap`, so its top edge follows the row's -- fixing the row's margin above moves the panel with it and there is no second number to keep in step. What the panel needs of its own is the CLOSE ROW: it is the Filter control in its other state, and on a phone it now matches the control it replaces rather than standing 20px taller than it. */ @media (max-width: 786px) { .lh-wrap.ttc-search-row-v2 > .lh-panel { padding-top: 18px; } .lh-wrap.ttc-search-row-v2 > .lh-panel .lh-close { min-height: 40px; margin-top: 10px; } } /* ===================================================================== ROUND 76, PHASE 3: THE THREE TYPE BUTTONS FIT ON ONE ROW ON A PHONE. MEASURED AT 390 BEFORE: each button is 153.7px wide -- 14px/26px of padding round a 16px label -- and three of them need 481px of a 314px row, so the group is 138px tall and "Pages (3)" sits on a line of its own under the other two. At 360 it is worse. The buttons are the page's own navigation and they belong side by side: a reader compares "Recipes (27)" with "News (2)" and "Pages (3)", and a tab that has fallen off the row does not read as a tab at all. So on a phone they are equal thirds of the row, sized by the row rather than by their own words, and the type and the padding come down to fit: 13px and 8px/6px against 16px and 14px/26px, on a 44px control -- the smallest a finger is reliably given, and 4px more than the Filter bar this round set at 40. Nothing above 600px moves. The 64px control, the 26px padding and the 16px label are the desktop's and they stay the desktop's. ===================================================================== */ @media (max-width: 600px) { .lh-wrap.ttc-search-row-v2 .lh-tools--tabs #subpages-menu nav { flex-wrap: nowrap; gap: 6px; width: 100%; } .lh-wrap.ttc-search-row-v2 .lh-tools--tabs #subpages-menu nav .simple-btn, .lh-wrap.ttc-search-row-v2 .lh-tools .simple-btn { flex: 1 1 0; min-width: 0; padding: 8px 6px; min-height: 44px; border-radius: 12px; font: 400 13px/1.2 Poppins, Montserrat, "Segoe UI", system-ui, Arial, sans-serif; text-align: center; } .lh-wrap.ttc-search-row-v2 .lh-tools .simple-btn strong { margin-left: .28em; } } /* ===================================================================== ROUND 76c, PHASE 1: THE BUTTONS STAND 10px OFF THE BAND. THE FILTER STILL TOUCHES IT. Tom's brief: the sort controls ("Best match" on the search page, "Organized by" on the recipe listings) and the search page's Recipes / News / Pages tabs take a 10px gap from the maroon band -- they are BUTTONS, and a button stands off the thing above it. The Filter bar is not a button in that sense: it is the band's own lower half, drawn with square top corners and 30px bottom ones so it reads as pulled out from under the band, and its gap stays 0. Round 76b's decision, recorded in QUESTIONS.md and in the block above, is unchanged and this round does not go near it. WHAT MOVES IS THE CHILDREN, NOT THE ROW. `.lh-tools` keeps `margin-top: 0`, so the row's own top edge is still on the band's bottom edge and `tools/search_row_gate_30.py`'s "the gap under the band is 0" is still the truth about the component. The 10px is a margin on the two controls inside it. WHERE THE 10 APPLIES, AND WHERE IT WOULD BE THE WRONG 10: the tabs every width. On a phone the row stacks and the tabs are still the thing directly under the band, so the gap is still a band gap. the sort 787 and up ONLY. Below that the row is a centred column and the sort is under the FILTER (or under the tabs), not under the band -- the space above it there is the component's own internal 10px gap, which listhead.css already sets and which this round must not double to 20. AND THE SIDE EFFECT, MEASURED AND NOT HIDDEN: on the recipe listings at 787 and up the Filter now starts 10px above the sort beside it, so their BOTTOM edges no longer line up either -- 64 against 74 from the band. The row is 10px taller for it. That is the direct consequence of 0 for one control and 10 for the other, it is flagged for Tom in ROUND-76c-REPORT.md with a picture, and nothing is guessed here to paper over it. `align-self: flex-start` is what stops the filter being STRETCHED to the taller row's height: the brief says the Filter does not change, and growing it from 64px to 74px would be a change. */ .lh-wrap.ttc-search-row-v2 .lh-tools--tabs #subpages-menu { margin-top: 10px; } @media (min-width: 787px) { .lh-wrap.ttc-search-row-v2 .lh-sort { margin-top: 10px; } .lh-wrap.ttc-search-row-v2 .lh-tools > .lh-filter { align-self: flex-start; } } /* AND THE GROUP IS THE HEIGHT OF THE BUTTONS IT HOLDS, SO THE 10 IS THE 10 A READER SEES. Measured at 390 with the rule above in place: the section `#subpages-menu` sat 10.0px under the band and the BUTTON inside it sat 14.0px under it -- the group keeps a 52px minimum height from round 25 while round 76 phase 3 brought the phone buttons down to 44px, and `align-items: center` put the 8px of slack half above them. The band gap is a gap a reader measures with their eye, between the maroon edge and the first painted button, so the empty 4px goes: below 600 the group is its content, exactly as listhead.css's own comment says it should be ("the group is the height of the buttons it holds"). Nothing above 600 moves -- there the buttons are 64px and already taller than the 52. */ @media (max-width: 600px) { .lh-wrap.ttc-search-row-v2 .lh-tools--tabs #subpages-menu { min-height: 0; } } /* ===================================================================== ROUND 76d, PHASE 1: WHEN "Best match" TAKES ITS OWN LINE, THE TABS ARE CENTRED TOO. Tom's brief: "when 'Best match' wraps below the Recipes/News/Pages tabs at narrow widths, the tabs stay left-aligned while the sort centres" -- centre the tab row as well, the tabs keeping their own size, so the two lines of the stack read as one centred block. Above the wrap point, unchanged. WHERE THE WRAP POINT IS, MEASURED AND NOT ASSUMED. `.lh-tools` becomes a centred COLUMN at 786 and below (listhead.css:103, and the queue-75 block above), so 787 is the last width at which the sort sits beside the tabs: 787 tabs 42.0 .. 470.2 sort 515.0 .. 745.0 same top edge 786 tabs 42.0 .. 470.2 sort 278.0 .. 508.0 its own line, centred THE 273.8px THIS CLOSES. At 786 the tab group is the full width of the row, 42.0 .. 744.0, and its three buttons sat at its left edge with 273.8px of empty row to their right, while the sort below them was centred to 0.0. The two lines of the same stack were aligned to different things. Measured before, left slack against right slack: 786 0.0 / 273.8 720 0.0 / 207.8 640 0.0 / 127.8 760 0.0 / 247.8 700 0.0 / 187.8 601 0.0 / 88.8 and the centre of the tab row ran 136.9px left of the sort's at 786, closing to 44.4 at 601. IT IS ONE DECLARATION, AND IT IS THE ONE listhead.css:274 SETS THE OTHER WAY. That file's `justify-content: flex-start` carries the comment "LEFT, not centred. The Filter bar's left EDGE is the reference" -- which is MY RECIPES' reasoning, where the row holds a full-width Filter bar for the buttons to line up with. The search page has no Filter bar in this row: below 787 it holds the tabs and the centred sort and nothing else, so there is no left edge to answer to, and the thing the tabs should line up with is the sort. This rule is scoped to `.ttc-search-row-v2`, so My Recipes' row is untouched. NOTHING CHANGES SIZE, AND BELOW 601 NOTHING CHANGES AT ALL. The buttons keep every width they had -- tools/q80_tabcentre.py compares all three against the recorded before, at all 23 widths -- because centring moves the free space, not the boxes. And from 600 down, round 76's phase 3 makes the three buttons equal thirds of the full row (`flex: 1 1 0`), so there is no free space to move: left slack and right slack were both 0.0 before this rule and both 0.0 after it. ===================================================================== */ @media (max-width: 786px) { .lh-wrap.ttc-search-row-v2 .lh-tools--tabs #subpages-menu nav { justify-content: center; } }