* * * Measured before this: the wrapper was transparent, 36px tall, radius 0, while * the INPUT carried the white fill and the 8px radius. The visible result was * close enough to pass a colour check and wrong in two ways -- 36px instead of * 40, and my own F3 focus ring drawn around a transparent box whose edges did * not match the white one the user sees. * * So the fill, the height, the radius and the ring all move to the wrapper, and * the input becomes what the component says it is: transparent and full height. * ------------------------------------------------------------------------- */ .sb-site-header .sb-algolia-search__field { display: flex; align-items: center; overflow: hidden; height: 40px; /* h-10 */ border-radius: 8px; /* rounded-lg */ background: #ffffff; box-shadow: 0 0 0 1px rgba(255, 255, 255, 0.2); /* ring-1 ring-white/20 */ } .sb-site-header .sb-algolia-search__input { height: 100% !important; background: transparent !important; border-radius: 0 !important; border: 0 !important; } /* --------------------------------------------------------------------------- * Two tray details from critic 7. * * F6: SanguineNav.tsx L262 puts the SAME `my-5 h-px bg-border` above Log out as * above the tiles -- 20px, a 1px rule on the border token, 20px. C1V4-D #42 * converted the FIRST divider and left the second on the old translucent black * with 12px/10px spacing. * * F11: L218 wraps the tray in `... bg-card p-6 text-foreground ...`. The theme * set no colour at all, so the root inherited white from the navy bar and every * descendant that does not set its own was one edit from white-on-white. Not * currently visible -- a contrast scan of the open tray found 0 nodes below * 2:1 -- which is exactly why it would have been found by a regression rather * than a review. * ------------------------------------------------------------------------- */ .sb-site-header .sb-site-header__account-tray { color: #141d2e; /* --foreground */ } .sb-site-header .sb-site-header__account-logout { margin-top: 20px; /* my-5 */ padding-top: 20px; border-top: 1px solid #dbdfe6; /* bg-border */ } /* * The tray's Close control (C6V4-G). SanguineNav.tsx puts it top-right of the * identity row, `text-muted-foreground` hovering to `text-foreground`, with a * 16px glyph. The tray is `position: absolute`, so this anchors to its padding * box rather than sitting in the flex row -- which keeps the identity block's * `gap-3` exactly as the component specifies it. */ .sb-site-header__account-close { /* * `!important` on position, and on every state (critic 10, F2/F3). * * A parent-theme rule -- `button:focus, button:active { position: relative }` * at (0,1,1) -- beat this at (0,1,0). So on MOUSEDOWN the button took focus, * flipped to `relative`, left its absolute slot and reflowed to the tray's * TOP-LEFT while the tray grew 418 -> 442px. The pointer was then no longer * over it at mouseup, so Chrome dispatched `click` on the common ancestor and * the button's own handler never ran: the Close control did nothing for a * mouse user, 6 trials of 6, on two routes. * * The handler was correct the whole time -- element.click() closed the tray, * and getEventListeners named the right function. Asserting the handler, the * class or the selector would all have passed. Only clicking it failed. */ position: absolute !important; top: 24px; right: 24px; display: inline-flex; align-items: center; justify-content: center; width: 20px; height: 20px; padding: 0; border: 0; background: transparent; color: #647690; /* --muted-foreground */ cursor: pointer; transition: color 120ms ease; } .sb-site-header__account-close:hover, .sb-site-header__account-close:focus, .sb-site-header__account-close:focus-visible, .sb-site-header__account-close:active { position: absolute !important; top: 24px; right: 24px; color: #141d2e; /* --foreground */ background: transparent; } /* * V6 CRITIC ROUND -- header type, against SanguineNav.tsx at Lovable HEAD. * * The search field is `text-sm` with no weight class, so it inherits normal. * Live rendered it at 500 from css/algolia-search-modern.css, which is not in * this changeset's deploy list -- so the correction is made here, in the file * the header actually owns, rather than by shipping an unaudited sheet. */ .sb-site-header .sb-algolia-search__input, .sb-site-header__search .sb-algolia-search__input { font-weight: 400; } /* * The promo chip's tracking is corrected in `.sb-site-header__strip-code` * above, which is the class the markup actually carries * (template-parts/header/site-header.php). Two selectors written here first -- * `.sb-site-header__promo-code` and `.sb-promo-bar__code` -- matched nothing * at all, which is the quietest way to ship a fix that does nothing. */ /* ===================================================================== * HOMEPAGE HERO — about 40% shorter, on Brian's instruction of 18 Sep. * * It measured 271px: a 166px slider viewport plus a 104px PAGER. The pager was * 104px because its four `.bx-pager-item`s were stacking -- each one 1440px * wide and 26px tall, one per line -- where a bxSlider pager is meant to be a * single row of links. So most of the height was a broken control strip, not * content. * * Laying the items out inline and floating the pager over the foot of the * slide removes the whole strip from the flow: the row becomes the viewport's * own 166px, which is 39% shorter and lands where Brian asked without touching * the slide's typography. * * WHY THIS LIVES IN site-header.css: it is the only site-wide stylesheet in * dm_deploy.FILES. A new file would need enqueueing from functions.php, which * is merge-only. The rules are scoped to .homepage_banner_row so nothing else * can be caught by them. * ===================================================================== */ .homepage_banner_row .bx-wrapper { position: relative; } .homepage_banner_row .bx-controls { position: absolute; left: 0; right: 0; bottom: 8px; height: auto; pointer-events: none; } .homepage_banner_row .bx-controls .bx-pager { display: flex; flex-wrap: wrap; align-items: center; justify-content: center; gap: 8px 16px; height: auto; padding: 0; } .homepage_banner_row .bx-controls .bx-pager-item { display: inline-flex; width: auto; height: auto; pointer-events: auto; } .homepage_banner_row .bx-controls .bx-pager-link { width: auto; height: auto; line-height: 20px; } /* * HERO, second cut — Brian, 18 Sep: "still too tall. Cut off the top 30-40% of * the hero image if you have to, we're replacing this page soon anyway." * * 166px -> 108px, another 35%. bxSlider writes the viewport height inline from * JS, so this overrides it and crops rather than rescaling: the slide is pulled * up by the 58px difference and the overflow is clipped, which takes the cut off * the TOP as asked and leaves the headline sitting on the fold. * * This is deliberately blunt. It fights the slider's own measurement instead of * reconfiguring the module, and it will need redoing if the slide content * changes height -- accepted because the page is being replaced. */ /* * THE BOTTOM IS NEVER CUT. THE PHOTO IS CROPPED; THE CONTENT IS NOT. * * Brian, 18 Sep: "I need them to NEVER cut off the bottom because that's where * my buttons and shit are." * * The previous version capped every box at a hard height with `overflow: * hidden`, which cropped the PHOTO correctly but also clipped * `.fl-slide-foreground` -- the headline, the copy and the buttons. Anything the * slide needed below 412px was simply cut off. * * So nothing is clipped by height any more. 412px is a MINIMUM: the boxes size * to their content and grow past it when a slide needs more room, so no * foreground element can ever be cut. The photo still shrinks to fit, because * `cover` + `background-position: bottom` crops it from the TOP against * whatever height the slide ends up with. * * `.bx-viewport` keeps `overflow: hidden` -- bxSlider lays the slides out in one * wide row and needs it to show only the current one -- but its HEIGHT is auto, * so it fits its content rather than cutting it. That is the difference between * this and the version that clipped. */ .homepage_banner_row, .homepage_banner_row .fl-row-content-wrap, .homepage_banner_row .fl-row-content, .homepage_banner_row .fl-col-group, .homepage_banner_row .fl-col, .homepage_banner_row .fl-col-content, .homepage_banner_row .fl-module, .homepage_banner_row .fl-module-content, .homepage_banner_row .fl-content-slider, .homepage_banner_row .bx-wrapper { height: auto !important; max-height: none !important; min-height: 0 !important; overflow: visible !important; } .homepage_banner_row .bx-viewport { height: auto !important; max-height: none !important; /* Horizontal clipping only -- this is what keeps one slide on screen. */ overflow: hidden !important; } /* 412 is the floor, not the ceiling. A taller slide makes the hero taller. */ .homepage_banner_row .bx-viewport > ul, .homepage_banner_row .bx-viewport > ul > li, .homepage_banner_row .fl-slide { height: auto !important; max-height: none !important; min-height: 412px !important; } /* The foreground is never constrained -- this is the bit with the buttons. */ .homepage_banner_row .fl-slide-foreground { height: auto !important; max-height: none !important; overflow: visible !important; } /* * THE PHOTO LAYER IS PINNED TO THE SLIDE, NOT SIZED AS A PERCENTAGE OF IT. * * `height: 100%` was the bug behind the blue bar (Brian, 18 Sep): the slide is * `height: auto` with a `min-height`, and a percentage height against an * auto-height parent resolves to AUTO. So the photo collapsed to its own * natural height, the slide stayed at 412, and the row's navy background showed * through underneath -- a different amount per slide, because each photo has a * different natural height. That is also why the crop looked inconsistent. * * Pinned with inset:0 it fills the slide box whatever height that box ends up * being, so there is never a gap and every slide crops identically: `cover` * anchored to the BOTTOM, which takes the excess off the top and never off the * buttons. */ .homepage_banner_row .fl-slide { position: relative !important; } .homepage_banner_row .fl-slide-bg-photo { position: absolute !important; inset: 0 !important; width: auto !important; height: auto !important; max-height: none !important; background-size: cover !important; background-position: bottom !important; } /* Keeps the headline, copy and buttons above the pinned photo. */ .homepage_banner_row .fl-slide-foreground { position: relative; z-index: 1; } .homepage_banner_row img { max-height: none !important; object-fit: cover; object-position: bottom; } .homepage_banner_row .fl-slide { background-size: cover !important; background-position: bottom !important; } /* * The 10px the tray hangs below the bar belongs to nothing, so the pointer * leaves the account wrapper while travelling from the icon to the tray and the * tray closes under it (Brian, 18 Sep). This bridges the gap with a transparent * strip that is part of the tray, so the journey never leaves the wrapper. * * Paired with the 400ms close delay in js/site-header.js -- the delay handles an * overshoot past the tray, this handles the gap itself. */ .sb-site-header__account-tray::before { content: ""; position: absolute; left: 0; right: 0; top: -12px; height: 12px; } /* * Lift the hero's headline and CTA off the bottom edge. * * Brian, 18 Sep: "the hero CTA and text just need to be bumped up a little." * With the slide at a 412px floor and the photo pinned behind it, the * foreground sat hard against the bottom of the frame. This is padding rather * than a height change, so it moves the content without re-cropping the photo * or reintroducing a clip. */ .homepage_banner_row .fl-slide-foreground { padding-bottom: 44px; box-sizing: border-box; } /* * THE BLUE BAR, KILLED AT THE SOURCE. * * Brian, 18 Sep, third report. Every fix so far has chased the GEOMETRY -- make * the photo fill the slide, cap this box, pin that one -- and each time a * different gap appeared, because I was reasoning about staging's layout from * local's, where the hero slide has no photo and no CTA. * * The bar is the ROW'S OWN NAVY BACKGROUND showing through wherever the photo * does not reach: bxSlider ships `.bx-wrapper { margin-bottom: 60px }` to make * room for its pager, and that margin sits outside the photo but inside the * row. * * So this stops trying to make the geometry perfect and removes the thing that * makes a gap VISIBLE. The slider's own spacing is zeroed, and the row is given * no background of its own -- the photo is full-bleed `cover`, so it is the * background. If a gap ever does appear again it will be the page behind it, * not a navy band, and it will not look like a rendering fault. */ .homepage_banner_row .bx-wrapper, .homepage_banner_row .bx-viewport, .homepage_banner_row .fl-content-slider, .homepage_banner_row .fl-module-content { margin: 0 !important; padding: 0 !important; border: 0 !important; box-shadow: none !important; background: transparent !important; } .homepage_banner_row, .homepage_banner_row .fl-row-content-wrap, .homepage_banner_row .fl-col-content { background-color: transparent !important; background-image: none !important; } /* The pager rides over the photo, so it never needs a strip of its own. */ .homepage_banner_row .bx-controls { position: absolute !important; left: 0 !important; right: 0 !important; bottom: 10px !important; top: auto !important; height: auto !important; margin: 0 !important; background: transparent !important; } /* * HERO PAGER — Brian, 18 Sep: "The first image in the hero slider now has a * white bar at the bottom. It looks like there's a random dot in the image * because the inactive dot/slides aren't visible." * * Both halves of that are the same control. bxSlider's `.bx-controls` was * dropping back into normal flow below the viewport, so it reserved its own * strip of page under the hero -- that is the white bar, and the hero itself is * not short. The rules above already position it absolutely; something loaded * after this file was resetting it, so these re-declare with enough weight to * hold and are placed last in the file so source order is on their side too. * * The "random dot" is the active pager link. The inactive ones were rendering * effectively invisible against the photo, so a four-slide pager read as a * single stray dot. They now carry a translucent white fill and a hairline * border, which stays legible over both the dark left side of the slide and the * lighter right, without competing with the active one. * * Sized 10px with a 20px hit area: the visual dot stays small, the tap target * does not. */ .homepage_banner_row .bx-wrapper { position: relative !important; } .homepage_banner_row .bx-controls { position: absolute !important; left: 0 !important; right: 0 !important; bottom: 14px !important; top: auto !important; z-index: 3; margin: 0 !important; padding: 0 !important; height: auto !important; min-height: 0 !important; background: none !important; pointer-events: none; } .homepage_banner_row .bx-controls .bx-pager { display: flex !important; flex-wrap: wrap; align-items: center; justify-content: center; gap: 0 4px; margin: 0 !important; padding: 0 !important; height: auto !important; background: none !important; /* bxSlider ships `position: absolute; bottom: -30px` on .bx-pager, which is what pushed the dots out from under the slide in the first place. */ position: static !important; } .homepage_banner_row .bx-controls .bx-pager-item { display: inline-flex !important; align-items: center; justify-content: center; width: auto !important; height: auto !important; margin: 0 !important; pointer-events: auto; } .homepage_banner_row .bx-controls .bx-pager-link { display: block !important; /* * Brian, 18 Sep: "now it's just a square instead of a circle." * * That was `background-clip: content-box`. border-radius rounds the BORDER * box; the content box keeps square corners, so clipping the paint to it * paints a square inside a rounded element. The padding trick cannot survive * a border-radius, so the dot is simply a 10px round element now and the * spacing comes from margin instead of a hit-area pad. */ box-sizing: border-box; width: 10px !important; height: 10px !important; padding: 0 !important; margin: 5px !important; border-radius: 50% !important; /* * Measured on prod: the inactive links were rgb(255,255,255) -- pure white. * Over the navy slide that is fine, but the pager can land on the white page * below the image, and there they vanish completely. That is the whole * "random dot" report: three dots were rendering, two of them invisible. * * So the inactive fill is a mid tone that holds contrast BOTH ways, with a * hairline ring so it still reads if it ever sits on plain white again. * Picking a translucent white here would have reproduced the bug. */ border: 0; box-shadow: none; text-indent: -9999px; overflow: hidden; line-height: 0 !important; opacity: 1; transition: background-color 0.15s ease; } .homepage_banner_row .bx-controls .bx-pager-link:hover, .homepage_banner_row .bx-controls .bx-pager-link:focus-visible { background-color: #c3cad8 !important; } .homepage_banner_row .bx-controls .bx-pager-link.active { background-color: #ee6c2d !important; } /* * THE WHITE BAR UNDER SOME SLIDES — Brian, 18 Sep: "the image has a big white * bar under it. None of the other images have that." * * Measured on prod at 1342px, walking the real chain from a short slide: * * .bx-viewport h=536 (inline height 460.375px, overridden) * .fl-content-slider-wrapper h=0 * .fl-slide (float:left) h=460 * * Two things, and my first attempt at this fixed neither because it was written * against markup that does not exist: this slider has NO

at all, so * every `.bx-viewport > ul > li` selector matched nothing. * * What actually happens: the slides are FLOATS, and .bx-viewport was * `height: auto; overflow: hidden`. That pair makes the viewport a block * formatting context, so it grows to contain the tallest float -- all five * slides, not the visible one. Slides measure 536/460/536/536/460, so whenever a * 460 slide is showing, 76px of empty viewport sits below it. That is the white * bar, and it is why it appears on some slides and not others. * * bxSlider's own inline height (the current slide's) was being overridden by that * `!important` auto, so the slider could not correct it either. * * Fixed by making the hero a DEFINITE height and stretching every slide to it, * so "tallest slide" and "this slide" are the same number and no gap can open. * A percentage needs a definite parent, which is exactly what `height: auto` was * denying it -- hence the explicit pixel heights here. * * Blunt on purpose, in keeping with the rest of this hero block: the page is * being replaced, and a deterministic height is worth more right now than a * self-measuring one that has produced a visible defect three times. */ .homepage_banner_row .bx-viewport { height: 440px !important; min-height: 0 !important; max-height: none !important; overflow: hidden !important; } .homepage_banner_row .fl-content-slider-wrapper { height: 440px !important; } .homepage_banner_row .fl-slide { height: 440px !important; min-height: 440px !important; } /* The photo is absolute inset:0 on the slide, so it follows automatically. The foreground has to be told, or the copy stays at its own content height. */ .homepage_banner_row .fl-slide-foreground { min-height: 440px !important; } @media (max-width: 992px) { .homepage_banner_row .bx-viewport, .homepage_banner_row .fl-content-slider-wrapper, .homepage_banner_row .fl-slide, .homepage_banner_row .fl-slide-foreground { height: 380px !important; min-height: 380px !important; } .homepage_banner_row .fl-slide-foreground { height: auto !important; } } @media (max-width: 600px) { .homepage_banner_row .bx-viewport, .homepage_banner_row .fl-content-slider-wrapper, .homepage_banner_row .fl-slide, .homepage_banner_row .fl-slide-foreground { height: 330px !important; min-height: 330px !important; } .homepage_banner_row .fl-slide-foreground { height: auto !important; } } /* * DOT COLOUR, AT A WEIGHT THAT ACTUALLY WINS. * * The inactive dots stayed pure white through two rounds of `!important`. * Asking the browser which rules matched settled it: * * .bx-wrapper .bx-pager.bx-default-pager a background:#fff !important * -- legacy-site.css, specificity (0,3,1) * .homepage_banner_row .bx-controls .bx-pager-link (0,3,0) * -- mine * * Both !important, so the winner is decided on specificity, and that trailing * bare `a` was worth exactly the one point I was short. Adding another * `!important` could never have fixed it. * * Restated here against legacy-site.css's own selector shape plus the archive * scope and the link's class, which puts it clearly ahead without resorting to * an id or an inline style. */ .homepage_banner_row .bx-wrapper .bx-pager.bx-default-pager a.bx-pager-link { background: #98a2b7 !important; } .homepage_banner_row .bx-wrapper .bx-pager.bx-default-pager a.bx-pager-link:hover, .homepage_banner_row .bx-wrapper .bx-pager.bx-default-pager a.bx-pager-link:focus-visible { background: #c3cad8 !important; } .homepage_banner_row .bx-wrapper .bx-pager.bx-default-pager a.bx-pager-link.active { background: #ee6c2d !important; } /* * AUTOIMMUNE/INFLAMMATORY GETS A FOURTH COLUMN — Brian, 18 Sep: "The expanded * Autoimmune/Inflammatory in the nav needs to be four columns as well... Just * that one category needs four columns, no others." * * It is the only area with enough conditions to need one: 65 links in the pane * against a 3-column default, so the list ran far past the panel and had to be * scrolled. Every other area fits in three. * * Scoped by the pane's own data attribute rather than by an nth-child position, * because the areas are ordered by the menu and a reorder would silently move * the fourth column onto whichever area happened to land in that slot. The slug * is therapeutic_area term 561, "autoimmune-inflammatory". * * Inside the 1100px breakpoint only: below it the panel is not wide enough for * four legible columns, and the 2/3-column defaults still apply there. */ @media (min-width: 1100px) { .sb-site-header__diseases-pane[data-sb-area-pane="autoimmune-inflammatory"] .sb-site-header__diseases-grid { column-count: 4; column-gap: 24px; } } /* * ONE SLIDE NEEDS NO PAGER — Brian, 18 Sep: "I just want one image that's * static, not a scrolling hero." * * The homepage hero is now a single slide (Beaver Builder post 34824, node * hmotay5nl6rd), but bxSlider still builds its pager and draws one dot. A single * dot under a static image is exactly the "random dot" reported earlier: it * advertises a control that cannot do anything. * * `:only-child` is the whole test -- one pager item means one slide. Written * this way rather than as a body class so it stays correct by itself if a second * slide is ever added back: the dots simply return. */ .homepage_banner_row .bx-controls .bx-pager-item:only-child { display: none !important; }