/* ===================================================================== ROUND 30, JOB 30.9 -- floating_bar_live THE SIDE SLIDER: Comments + Share. Reached only through `.ttc-v2.ttc-floating-bar`, which app/switches.py puts on the wrapper when `floating_bar_live` is set. Off, the markup is not emitted at all and not one declaration here matches. MEASURED BEFORE BUILDING -- the left gutter at 1440, which the README left open. tools, on /preview-v3/60-min-pan-pizza/: 1440 column x=97.5 w=1245 LEFT GUTTER 97.5px RIGHT 97.5px 1024 column x=0 w=1024 LEFT GUTTER 0px 768 column x=0 w=768 LEFT GUTTER 0px 390 column x=0 w=390 LEFT GUTTER 0px AND NOTHING ALREADY LIVES IN IT at any of the four widths -- every element whose right edge is left of the column was enumerated and the list is empty. The bar needs 66 and `left:30px` puts it at 30..96, which clears the column by 1.5px at 1440. Below about 1150 the gutter closes and the bar floats OVER the content, which is what the drawing's TABLET panel at 834px shows. ROUND 83: THE 97.5 ABOVE IS STALE AND THE "CLEARS BY 1.5px" WITH IT. The column has grown since round 30 and the 1440 gutter measures 78.7 today, so `left:30px` put the bar 17.3px ONTO the reader's text rather than 1.5px clear of it -- a note that was true when it was written and had quietly stopped being true. Re-measured on the same page, same tool: 1600 gutter 105.3 1440 gutter 78.7 1280 gutter 30 1024 gutter 20 834 gutter 20 768 gutter 20 Left in place rather than deleted so the drift itself is on the record. THE DRAWING, 02-floating-bar.jpg, three panels: PHONE 390px RIGHT edge, 38px skinny, icons only, flat on the edge TABLET 834px LEFT gutter, 66px, a label under each icon DESKTOP 1440px floats clear of the 1245px column, not on the window edge ===================================================================== */ .ttc-fbar { position: fixed; top: 50%; transform: translateY(-50%); z-index: 60; display: flex; flex-direction: column; background: #51000d; box-shadow: 0 3px 16px rgba(81, 0, 13, .38); overflow: hidden; transition: opacity .22s ease, transform .22s ease; } /* NOT SHOWN ON LOAD: the hero photograph gets the screen to itself. The class is on the element from the start and the script takes it off once the hero has scrolled past, so there is no flash of a bar before the script runs. */ .ttc-fbar.is-hidden { opacity: 0; pointer-events: none; } .ttc-fbar button { appearance: none; border: 0; background: transparent; width: 100%; display: grid; place-items: center; cursor: pointer; color: #fffeec; padding: 0; } .ttc-fbar button + button { border-top: 1px solid rgba(255, 254, 236, .22); } .ttc-fbar button:hover { background: #6a0b19; } .ttc-fbar button:focus-visible { outline: 2px solid #fffeec; outline-offset: -3px; } .ttc-fbar .lab { font: 700 8.5px/1.1 Poppins; letter-spacing: .03em; color: #fffeec; } .ttc-fbar svg { fill: none; stroke: #fffeec; stroke-width: 1.9; stroke-linecap: round; stroke-linejoin: round; } /* ---- ROUND 83, PHASE 3: BIGGER, AND OFF THE COLUMN -------------------- Three things were asked for and the numbers behind each are below. MEASURED FIRST, on /recipes/60-min-pan-pizza/ with the bar on screen, the content column's LEFT GUTTER against the band the bar occupies: width gutter bar was over the column bar is over it 768 20 730..768 R 18 0..79.2 59.2 834 20 796..834 R 18 0..79.2 59.2 1024 20 30..96 66 0..79.2 59.2 1280 30 30..96 66 0..79.2 49.2 1440 78.7 30..96 17.3 0..79.2 0.5 1600 105.3 30..96 0 0..79.2 0 SO: "flush to the left edge so it no longer overlaps the page content" is completely true at 1600 and 1440, where the gutter is wide enough to hold the bar, and it is an IMPROVEMENT and not a cure at 1280 and below, where the column's own gutter is 20-30px and NO bar of any width can sit clear of it. The round-30 note above quoted a 97.5px gutter at 1440; the column has grown since and it is 78.7 now, which is why the bar had crept onto the text. Reported with these numbers rather than claimed. QUESTIONS 83. THE PHONE KEEPS ITS SIDE. "Mobile: make the bar 30% bigger; change nothing else" is explicit, and the drawing 02-floating-bar.jpg puts the PHONE panel flat on the RIGHT edge. Moving it would not be a size change. The tablet, which the phase does name, moves to the left with the desktop -- so the breakpoint between the two rules goes from 1023/1024 to 767/768, because 768 and 834 are tablets and were being drawn by the phone's rule. QUESTIONS.md 83 (g): this is the one question I would most like answered. EVERY NUMBER IS THE OLD ONE TIMES 1.3 (phone) OR 1.2 (tablet + desktop), written out so the arithmetic can be checked: phone width 38 -> 49.4 button 40 -> 52 icon 20 -> 26 radius 13 -> 16.9 desktop width 66 -> 79.2 padding 12/4/10 -> 14.4/4.8/12 gap 5 -> 6 icon 23 -> 27.6 radius 14 -> 16.8 THE LABEL IS THE ONE EXCEPTION AND IT IS DELIBERATE. 8.5px x 1.2 is 10.2px, which is still too small to read, and the phase asks for the labels themselves to be "clearly readable" as a separate instruction from the 20%. 11.5px, measured against the 69.6px of room inside the wider bar: "Comments" sets at 57.6px, so it fits on one line with 12px to spare and `white-space: nowrap` fails loudly rather than wrapping if that ever stops being true. */ /* ---- ROUND 84, PHASE 1: THE SIDE IS DECIDED BY MEASUREMENT -------------- Round 83 put the bar flush LEFT at 768 and above and reported honestly that this was an improvement and not a cure: at 768-1180 a 79.2px bar on the left reaches 59.2px INTO the reader's column, because the column's own left gutter there is 20px and no bar of any width can sit clear of it. Tom's round-84 answer is to give the tablet the OTHER side. SO THE QUESTION BECAME: on which side, at which width, are there no LETTERS under the bar? Measured with tools/fbar_overlap_84.py, which does not ask where an element's BOX is -- a

spans the whole column while its last line may end 300px short -- but where the GLYPHS are, via Range.getClientRects() on every text node, at eight scroll positions per width so a bar that is clear halfway down the page cannot pass for clear. THE TABLE THAT DECIDED EVERY BREAKPOINT BELOW. Deepest ink under a band of the given width, /recipes/60-min-pan-pizza/ and /recipes/pulled-pork/: width LEFT band 79.2 RIGHT band 79.2 RIGHT band 42 390 29.4 * 7.4 0 414 29.4 * 7.4 0 768 59.2 37.2 0 834 59.2 37.2 0 860 59.2 37.2 0 900 59.2 37.2 0 960 59.2 37.2 0 992 59.2 37.2 0 1008 59.2 37.2 0 1024 59.2 0 0 1180 59.2 0 0 1280 11.2 0 0 1340 11.2 0 0 1360 2.5 0 0 1380 0 0 0 1440 0 0 0 1600 0 0 0 (* at a 49.4px phone band) THREE THINGS FALL OUT OF IT, and each is a breakpoint: 1024 is a REAL EDGE, not a guess: at 1008 the right band still carries 37.2px of ink and at 1024 it carries none, because the site's own layout opens the column's right gutter there. Below it the clear right gutter measures exactly 42px on every width tested, which is why the narrow tablet bar is 42px and not 79.2 -- "tuck it into the right gutter" is meant literally. 1400 is where the LEFT is clean with room to spare. The last ink on the left is 2.5px at 1360 and none at 1380 -- the "Before You Start" heading, which sits hard against the column's left edge -- so the desktop rule starts at 1400 rather than 1380 to leave 20px of margin for a longer heading on a recipe this did not measure. 1440, the width Tom quotes his 0.5px from, is inside it and keeps the LEFT side and that 0.5px exactly. 767/768 stays where round 83 put it. THE PHONE IS THE ONE PLACE WHERE "no text covered" CANNOT BE HAD, and the number is in the table above: the phone column's gutter is 20px and the bar is 49.4px, so the bar is over the column on EITHER side and no arrangement of those two numbers makes it zero. Round 84 put it on the LEFT because the phase said so, and measured what that cost: 29.4px, on EVERY line, because every line STARTS at the same x. QUESTIONS.md 84 (b) asked about it. ------------------------------------------------------------------------ */ /* ---- ROUND 85, PHASE 1: THE PHONE JOINS THE TABLET ON THE RIGHT ---------- Tom's answer to 84 (b). The intended design is now stated as three bands and a side each: PHONE right, TABLET right, WIDE DESKTOP left. THE ONE NUMBER THIS CHANGES, measured by tools/fbar_overlap_85.py the same way as every number above -- INK, via Range.getClientRects(), at eight scroll positions on five recipes: phone side deepest letter under the bar frames with any letter 390 LEFT 29.4 5 of 5 414 LEFT 29.4 5 of 5 390 RIGHT -- measured after the move, below 414 RIGHT -- AND WHY THE SIDE MATTERS MORE THAN THE DEPTH. A left-attached bar covers the FIRST letters of every line: every line begins at the column's left edge, so every line loses its opening and the depth is the full 29.4px on all of them. A right-attached bar reaches the RAGGED ENDS, and a line only loses anything when it happens to run nearly the full measure -- most lines stop short of it and lose nothing at all. That is the whole of round 84's complaint ("it clips the start of every line") and it is what moving the bar cures. The gate now prints BOTH the depth and the COUNT OF FRAMES with any letter under the bar, so "it only grazes ragged ends" is a measurement. NOTHING ELSE MOVES. The size is round 83's 30%-bigger phone bar, unchanged to the decimal -- 49.4px wide, 52px buttons, 26px icons, 16.9px radius. The tablet stays on the right, the desktop stays on the left, and the desktop drop shadow is untouched; the gate re-asserts all three so that moving the phone cannot quietly move one of them. THE THREE THINGS THAT FLIP WITH THE SIDE, and nothing else does: the edge `left: 0` -> `right: 0`, with the other set to `auto` so the desktop rule's `left` cannot leak in at a narrow width the corners the rounded pair moves to the side facing the page, which is the tablet's `16.9px 0 0 16.9px` at the phone's radius the hide the bar slides OFF the right edge now, so the sign on the translate goes positive -- a negative one would have slid it further onto the text it is hiding from. ------------------------------------------------------------------------ */ @media (max-width: 767px) { /* PHONE: RIGHT edge, skinny, icons only */ .ttc-fbar { right: 0; left: auto; width: 49.4px; border-radius: 16.9px 0 0 16.9px; } .ttc-fbar button { height: 52px; } .ttc-fbar button svg { width: 26px; height: 26px; } .ttc-fbar .lab { display: none; } .ttc-fbar.is-hidden { transform: translateY(-50%) translateX(18.2px); } } @media (min-width: 768px) and (max-width: 1023px) { /* NARROW TABLET: the RIGHT gutter, and nothing but the gutter. 42px is the measured width of the clear band at every width from 768 to 1008, so the bar is 42px and carries icons only -- "Comments" sets at 57.6px and cannot be made to fit in 42 without shrinking it back below the size round 83 was asked to grow it to. The icon keeps the phone's 26px. */ .ttc-fbar { right: 0; left: auto; width: 42px; border-radius: 16.8px 0 0 16.8px; } .ttc-fbar button { height: 52px; } .ttc-fbar button svg { width: 26px; height: 26px; } .ttc-fbar .lab { display: none; } .ttc-fbar.is-hidden { transform: translateY(-50%) translateX(18px); } } /* ---- ROUND 86b, RULE (d): THE NEWSLETTER DECIDES THE SIDE ---------------- A SITE-WIDE RULE, and an addition to the three bands above rather than a replacement for them: wherever the newsletter sign-up window is on the RIGHT, the bar is on the LEFT -- always. The bar may take the right only where there is no sign-up there to take it from. SO THE BREAKPOINT IS NOT A TASTE, IT IS THE RAIL'S OWN. Measured on the candidate, six page types, `#main-right` and the newsletter box inside it: width #main-right floating bar, round 85 rule 390 display:none RIGHT 340.6..390 768 display:none RIGHT 726..768 1024 display:none RIGHT 944.8..1024 1180 display:none RIGHT 1100.8..1180 1200 display:none RIGHT 1120.8..1200 1201 x868 w303 RIGHT 1121.8..1201 <- 49.2px ON the rail 1280 x947 w303 RIGHT 1200.8..1280 <- 49.2px ON the rail 1366 x1021 w303 RIGHT 1286.8..1366 <- 37.2px ON the rail 1400 x1038 w303 LEFT 0..79.2 1920 x1492 w303 RIGHT-free, bar LEFT The rail turns on at EXACTLY 1201 -- 1200 is display:none and 1201 is a 303px column -- and the bar stayed on the right until 1400, so 1201..1399 was the band where the sign-up and the bar were both on the right and the bar sat on top of the sign-up. Round 86 measured that overlap and reported it as pre-existing; this is the round that closes it, by moving the two breakpoints onto the rail's own edge: 1024..1399 RIGHT -> 1024..1200 RIGHT (no rail below 1201) >=1400 LEFT -> >=1201 LEFT (rail present from 1201) WHAT IT COSTS, MEASURED AND NOT GUESSED. The left band is not free at these widths: round 84's ink table (above) reads 11.2px of glyph under a 79.2px left band at 1280 and 2.5px at 1360. tools/fbar_side_86b.py re-measures it the same way -- Range.getClientRects(), eight scroll positions -- and prints the number for every width, so the trade is on the record: a few pixels of ragged line-start against 37-49px of the newsletter sign-up. Tom's rule settles which of those two is worse. NOT GATED BY `ad_slots_live`. Tom wrote this as a site-wide rule, and it is about the sign-up and the bar -- two things that are on the site today with no advertising anywhere near them. It therefore takes effect on the next deploy of any kind, which is said plainly in the round's report. ------------------------------------------------------------------------ */ @media (min-width: 1024px) and (max-width: 1200px) { /* WIDE TABLET: the RIGHT side, at the full labelled size. From 1024 up the right band is clear all the way out to 79.2px, so nothing has to be given up here -- this is round 83's bar, on the other side. ROUND 86b: the band ENDS at 1200, because 1201 is where the newsletter rail appears on the right and rule (d) hands the right to the sign-up. */ .ttc-fbar { right: 0; left: auto; width: 79.2px; border-radius: 16.8px 0 0 16.8px; } .ttc-fbar button { height: auto; padding: 14.4px 4.8px 12px; gap: 6px; align-content: center; } .ttc-fbar button svg { width: 27.6px; height: 27.6px; } .ttc-fbar .lab { font: 700 11.5px/1.1 Poppins; letter-spacing: .01em; white-space: nowrap; } .ttc-fbar.is-hidden { transform: translateY(-50%) translateX(18px); } } @media (min-width: 1201px) { /* NEWSLETTER ON THE RIGHT: bar flush LEFT */ /* ROUND 86b (d): 1400 -> 1201, the width at which `#main-right` stops being display:none. 1440 and everything above it keep exactly the rule they have today; what is new is 1201..1399, which used to be on the right on top of the sign-up. */ .ttc-fbar { left: 0; right: auto; width: 79.2px; border-radius: 0 16.8px 16.8px 0; } .ttc-fbar button { height: auto; padding: 14.4px 4.8px 12px; gap: 6px; align-content: center; } .ttc-fbar button svg { width: 27.6px; height: 27.6px; } .ttc-fbar .lab { font: 700 11.5px/1.1 Poppins; letter-spacing: .01em; white-space: nowrap; } .ttc-fbar.is-hidden { transform: translateY(-50%) translateX(-18px); } /* THE DROP SHADOW, AND WHY IT IS TWO SHADOWS AND NOT ONE. The bar is #51000d, very nearly black, and it is asked to "stand out on dark backgrounds". A dark shadow cannot do that -- dark on dark is invisible, which is exactly what the base rule's `0 3px 16px rgba(81,0,13,.38)` does against a dark photograph. So the LIGHT half does the work the phase asks for: a 1px cream ring draws the bar's own edge, and a soft cream glow lifts it off whatever is behind. The dark half is kept underneath for the opposite case -- the bar over a pale photograph or the cream page ground, where a light halo does nothing and a shadow is what separates it. Both are deliberately faint: .22 and .16 on the cream, .30 on the black. */ .ttc-fbar { box-shadow: 0 0 0 1px rgba(255, 254, 236, .22), 0 0 22px rgba(255, 254, 236, .16), 0 4px 18px rgba(0, 0, 0, .30); } } /* THE DESKTOP SHARE POPUP uses the page's OWN Facebook, Pinterest and email icons -- the same `.ic.fb`, `.ic.pin` and `.ic.at` anchors the hero's share block already paints, with the same stylesheet rules. README rule 7: draw nothing. On a phone the button calls navigator.share() and this never opens. */ .ttc-fbar-pop { position: fixed; z-index: 61; display: none; background: #fffeec; border-radius: 14px; padding: 10px 12px; box-shadow: 0 6px 24px rgba(81, 0, 13, .28); } .ttc-fbar-pop.open { display: flex; gap: 10px; align-items: center; } /* PHASE C. IT HAS TO BE A SMALL POPUP, AND IT WAS A BAR ACROSS THE PAGE. FOUND BY OPENING THE SCREENSHOT. `position: fixed` with only `top` and `left` set leaves the width to the containing block, so a flex row of three 44px icons stretched from the bar to the right-hand edge of the window -- 1,330px of cream at 1440. The spec says "a small popup with the site's Facebook / Pinterest / email icons", and every check in fbar_spec_c.py passed while it looked like that, because they all asked about the bar and none of them asked how wide the popup was. Shrink-to-fit is what it always should have been. */ .ttc-fbar-pop { width: max-content; max-width: min(90vw, 260px); }