/* --------------------------------------------------------------------------- footer-v2.css - tap targets for the footer link row. THE DEFECT (QA task 3.3, D2). Six controls in the footer - the five nav pills Home / Modules / About / Blog / Contact and the Instagram button - measured 21 to 32 px tall on phones and as little as 26.7 px wide, against the 44 px minimum this project gates every touch control on. Measured with elementFromPoint at 0.5 px steps: control 320 390 767 1024 1440 footer pill 35.8 x 21.4 43.6 x 26 53.6 x 32 28.6 x 17.1 40.2 x 24 Instagram 26.7 x 26.7 32.6 x 32.6 40 x 40 21.3 x 21.3 30 x 30 1024 is the smallest of the five and that is not a typo: Webflow's adaptive --size-unit resolves 1em against the viewport, and every one of these boxes is em-sized, so the row is smallest wherever the scale happens to bottom out rather than wherever the screen is narrowest. It is the same trap that produced a 16.9 px hamburger and a 36.5 px CTA elsewhere in this folder. --------------------------------------------------------------------------- WHY THIS IS NOT THE SAME ONE-LINER THE HEADER GOT. The five header controls were fixed with absolutely-positioned ::after hit areas so that no layout box moved (nav-v2.css, trap 7). Height here can be fixed the same way. WIDTH CANNOT, and the arithmetic is the reason: at 320 the row is 286.6 px wide and holds six controls whose boxes total 238.5 px with 2.7 px gaps between them. A ::after that bleeds sideways to reach 44 px would need (44 - w) / 2 of clearance on each side of every narrow control, and the row does not have it: About|Blog needs 6.9 px against a 2.7 px gap at 320, and 14.4 px against a 2.1 px gap at 1024. The hit areas would overlap, one control would swallow its neighbour's taps, and the gate would read as passed while the row was actually worse than before. A height-only fix has exactly that shape - which is why the QA pass changed nothing here and escalated it instead. SO WIDTH IS REAL AND HEIGHT IS A HIT AREA, and each is the cheapest correct answer for its own axis: * min-width: 44px on the control itself. Real boxes in a flex row cannot overlap, so non-overlap is a property of the layout rather than something to be re-measured every time the labels change. It costs a few px of extra spacing on the three short labels and nothing at all on the rest. * a 44 px ::after for height, centred on the box. Height is where the ::after pattern is safe: there is only ever one row of controls here, so there is no neighbour above or below to collide with - the wordmark above is not interactive and the footer bottom bar is 13 to 45 px clear at every width (measured, see PERF-RESULTS.md). THE ROW HAS TO BE ABLE TO WRAP, and only at the very bottom of the ladder. With six 44 px minimums the row needs 288.5 px at 320 and has 286.6 - it misses by under 2 px. Rather than shave a control to fit, the row wraps: the five pills stay on one line and Instagram takes its own, centred. That is a real layout change and it is deliberately confined to widths where it is forced - `.footer-main_links` already carries flex-wrap from the bundle, so the only additions are a row-gap big enough to keep two rows of hit areas apart and a centred justification for the wrapped line. Linked by STRUCTURAL EDIT 48 in _build/localize.py, BEFORE cta-v2.css, which must stay the last in (see edit 26). Nothing here competes with that file: it styles .button-073.is-cta in the CTA block above, this styles .button-073.is-nav / .is--social inside .footer-main_links, and the two sets are disjoint. --------------------------------------------------------------------------- */ /* --------------------------------------------------------------- width --- */ /* .button-073 is already position:relative in the bundle, so the ::after below needs no positioning context added. 45px, NOT 44 - pre-ship review finding L7, 28 Aug 2026, and the extra pixel is a measurement artefact rather than a change of mind about the gate. The 0.5px elementFromPoint probe this project measures tap targets with reads a control by walking outward from its centre until the point stops belonging to it, so a genuinely 44.0px-wide control reads 44.5 (22 left + 22 right + the centre step). Every control in the header reads 44.5 or better. These read EXACTLY 44.0 - half a step short - because their boxes sit on fractional coordinates: the row is em-sized off Webflow's adaptive --size-unit, so a pill's centre lands at something like x=140.7, and elementFromPoint resolves to device pixels, which costs half a step on one side. The rendered box really is 44; the reachable area is 43.5. Half a pixel is not a usability problem. It is a gate problem: 43.5 fails a >=44 check, and a project that measures this with a documented convention has to satisfy the convention rather than explain it away in every future report. 45 puts every one of them at 44.5 or better with any subpixel placement, and costs at most 1px of width on the three shortest labels. Re-checked against the wrap arithmetic below: six 45px controls need 294.5px at 320 where the row has 286.6, so the row still wraps there and only there. */ .footer-main_links .button-073 { min-width: 45px; } /* The Instagram button is the one control here that is drawn as a box rather than as bare type - .button-073.is--social is width:2.5em / height:2.5em and its .button-073__bg fill is visible at rest. min-width alone would therefore turn a 26.7px SQUARE into a 44 x 26.7 rectangle, which is a visible change to a shape whose whole point is being square. It gets both dimensions instead: still square, now 44px, and the icon inside is centred by the rule below. */ .footer-main_links .button-073.is--social { min-height: 45px; /* 45, not 44 - see the min-width note above (finding L7) */ } /* The bundle's .button-073__text is justify-content:flex-start, so on a control that min-width has widened the label would sit against the left edge with all the new space on the right. Centring puts it back on the box's optical centre; on every control whose natural width already clears 44 px the box is its content and centring is a no-op. */ .footer-main_links .button-073 .button-073__text { justify-content: center; } /* -------------------------------------------------------------- height --- */ /* 44 px tall, centred on the box, full box width (so it never narrows a control that is already wider than 44). Invisible, no layout box moves, and it is part of the anchor so it extends the anchor's own hit area. ::before, NOT ::after, and that is the one thing here that is not a matter of taste. The source already owns .button-073::after - it is the focus ring: .button-073::after { content:''; position:absolute; inset: var(--button-073-focus-inset); border-radius: var(--button-073-border-radius); transition: box-shadow ..., scale ...; pointer-events: none; z-index: 1 } .button-073:is(:focus-visible)::after { box-shadow: 0 0 0 0.125em ...; scale: var(--button-073-hover-scale) } The first draft of this file used ::after and it FAILED SILENTLY IN BOTH DIRECTIONS - it stretched the keyboard focus ring to 44px, and it inherited that rule's `pointer-events: none`, so the hit area it was supposed to create did not hit-test at all. Measured after that draft: width fixed at 43.5-52.5, height still 21.5. ::before is unused by the component - grepped across the vendored sheet and every inline