/* * RideXpress -- Legacy SEO/content-body family: Design 2.0 body redesign * Wave 42 Final Pass, item 1 * * WHY THIS FILE EXISTS * Track B/C (earlier this wave) redesigned the hero, booking widget, trust * section, FAQ, related-routes and closing CTA that wrap every one of the * ~8,798 pages in this family (see airportbase.html / outstationbase.html). * What sits BETWEEN those -- the page's own article body, rendered by each * child template's own {% block airport_content / oustation_content %} -- * was deliberately left untouched by every prior track (airportbase.html's * own header comment: "Nothing here can restyle a legacy element on the * ~8,804 pages this reaches"). That content is still 100% legacy markup: a * sidebar, an article image, and article prose using a small, fixed set of * class names with NO Design 2.0 treatment. This file is that treatment. * * WHAT WAS ACTUALLY WRONG, confirmed by rendering real pages, not just * reading source -- three real defects, not just "looks dated": * 1. .service-single-area had NO background rule anywhere in this repo -- * it silently inherited body,html{background-color:#000}, so the * article region rendered as plain text on raw black. * 2. .widget-title carries a pre-existing color:var(--color-dark)!important * (dark navy). With no card background behind it, that was dark-navy * text on a black page -- a real contrast/legibility bug, not merely * "unstyled". * 3. h1..h6 in this family inherit style.css's sitewide * h1,h2,h3,h4,h5,h6{color:var(--color-white)} (plus one explicit * .service-details h3{color:#fff}). That is only readable BECAUSE the * page background is black; fixing defect #1 without also overriding * heading color here would make every heading vanish. * A fourth, smaller issue fixed in passing: .service-details-img img had NO * rule at all on the ~528 pages where the image sits as a SIBLING of * .service-details rather than a descendant -- style.css's pre-existing * `.service-details img{height:20%;width:100%}` only ever matched pages * where the image nests INSIDE .service-details, and even there * `height:20%` is a no-op/distorting rule with no defined parent height. * * COVERAGE, verified by grepping the full template tree with exact * class-token matching before writing a single rule below (not assumed -- * an early pass at this comment wrongly guessed the sibling-image * structure was the majority case; it is not, see below): * .service-single-area 8,797 of 8,798 files; NEVER nests or repeats * .service-sidebar same reach; repeats 2-3x on ~435 pages (a * richer sub-layout used under templates/website/ * seo/stephen-seo/, ~1,824 files, that renders * several related-link cards in a row instead of * one sidebar) * .widget.category / .widget-title / .category-list * .service-details-img / .service-details -- DOUBLE/MULTI-NESTED * (.service-details > .service-details, or * siblings each with a nested .service-details) * on 8,267 of the 8,795 files that have any * .service-details at all -- the DOMINANT * pattern across the whole family, not a minor * "outstation" special case. Only 528 files use * the simpler single/sibling structure. Every * rule below that touches .service-details is * written per-descendant-tag (h1..h6/p/ul/a), * NEVER as a background/border/padding on the * class itself, so nesting depth cannot compound * a card-in-a-card. See the section 4 comment. * .featured-snippets repeats independently on 55 pages with >1 FAQ * block; also never nests inside itself. * * WHAT THIS FILE DELIBERATELY DOES NOT DO: edit any of the ~8,798 template * files, change any URL/canonical/sitemap/robots/structured-data/per-page * copy, or touch the already-redesigned hero/booking widget/trust/FAQ/ * related/CTA sections (design-system/journey-patterns.css and the * _journey_page_*.html partials render those as DOM siblings of the * content this file targets, never as descendants of it). * * All colors below use the *theme-adaptive* token aliases (--rx-color-text, * --rx-color-surface[-alt], --rx-color-border, --rx-color-accent-strong) -- * confirmed against tokens.css's dark-mode blocks before use. --rx-color-ink * and --rx-color-brand-strong were deliberately AVOIDED for text/background * here: both are static (never redefined under prefers-color-scheme:dark or * [data-theme="dark"]), so using them would silently repeat this exact wave's * own dark-mode-header bug (dark-on-dark text) the moment a visitor's OS is * in dark mode. Literal fallbacks match each token's :root (light) value, * for the rare case tokens.css fails to load, per the convention already * established in website/partials/_journey_page_tail.html. * * Loaded by airportbase.html and outstationbase.html's extra_css block, * after tokens/components/patterns/journey-patterns.css -- see those two * files' header comments, updated alongside this file. */ /* ---------- 1. Outer section: fix the raw-black-background defect ---------- Confirmed 0/8,798 files nest or repeat .service-single-area -- safe to background once. Uses the SAME token _journey_page_tail.html already uses for the Design 2.0 sections rendered immediately after this content (.rx-seo-page__sections), so the page's own body content and the shared tail sections now form one continuous light band instead of a jarring black-to-cream seam. Setting color here is required, not decorative: style.css's sitewide body{color:var(--body-text-color)} (#d2d6e0, a light grey-blue tuned for a dark page) is illegible against this new light background; every descendant that doesn't set its own color inherits this instead. */ .service-single-area { background: var(--rx-color-surface-alt, #F7F6F3); color: var(--rx-color-text, #132435); } /* Links and icons anywhere in this family -- one rule instead of repeating per sub-section, since every target below (.category-list, prose links, the two internal-link