/*! * Codex Site Fixes 0.2.6 * * Small, always-loaded corrections for defects measured on the four older sites. Kept apart from * codex-premium-blocks.css because that file only loads on pages containing a codex-* block, and * these defects appear on every page: on economad only 21% of the pages carrying the opt-in box * also carry a block marker, so the gated stylesheet would have missed four fifths of them. */ /* -------------------------------------------------------------------------------------------- 1. THE FREE-DOWNLOAD BOX SHOWED ITS PREMIUM COVER AT 82 PIXELS. Measured 2026-10-08 on mindclarityhub.com/journals-for-productivity/: the opt-in box is 1140px wide and its cover image is a 1024x1024 PNG, rendered at 82x82. At that size the cover reads as a small grey square - you cannot tell it is a book mockup at all, which is exactly why the box looked like it had never been given the premium image. It had; it was just 82px. This is the same defect the lead-magnet landing generator fixed on the landing pages ("the mockup is displayed at 80 pixels wide ... it reads as a small grey smudge"). The in-post box was never fixed because it is rendered by the bridge plugin, not by that generator. NOT a content problem: the image URL in those 621 posts is fine. The August and September mockups were compared byte for byte - both 1024x1024, both exactly 526,489 bytes - so they are the same picture under two filenames, and rewriting the URL in 621 posts would have changed nothing a reader can see. !important is required because the bridge prints its own .codex-reach-optin-thumb rule with the same specificity, and its stylesheet position relative to this one is not guaranteed. -------------------------------------------------------------------------------------------- */ .codex-reach-optin-thumb { width: clamp(104px, 13vw, 160px) !important; height: auto !important; aspect-ratio: 1 / 1; object-fit: contain; } /* The header is a flex row; at narrow widths a 160px cover plus the headline no longer fits on one line, so let it wrap rather than squeezing the text to a column of single words. */ @media (max-width: 560px) { .codex-reach-optin-header { flex-wrap: wrap; } .codex-reach-optin-thumb { width: clamp(96px, 26vw, 128px) !important; } } /* -------------------------------------------------------------------------------------------- 2. A COLLAPSED AUTO-ADS SLOT LETS ITS AD PAINT OVER THE ARTICLE. Measured 2026-10-08 on mindclarityhub.com/4-types-of-stress/: of 11 Auto Ads slots, two had an inline height of 0px while still containing a rendered 150px ad iframe. Google sets that height itself, and because the iframe is position:absolute it contributes nothing to the container, so the ad overflowed and collided with the "Reader resource" box below it - which is what reads as an ad being cut off or clipped. This CSS is only the belt. It cannot know how tall a given ad is, so the actual correction is in codex-ad-slot-guard.js, which measures the rendered iframe and grows only the containers that are genuinely too short. What CSS can safely do is stop a collapsed container from clipping an ad that is already inside it, and make sure an ad can never sit on top of following content. -------------------------------------------------------------------------------------------- */ ins.adsbygoogle { overflow: visible; } /* Set by the guard script, never by Google. Scoping the rule to this attribute means nothing here applies to a slot the script has not measured and judged to be short. */ ins.adsbygoogle[data-codex-ad-fix="1"] { display: block; position: relative; } /* -------------------------------------------------------------------------------------------- 3. wpautop PUTS A
INSIDE LINKS, AND THE EXISTING BACKSTOP ONLY COVERS CLASSED ONES. Measured 2026-10-08 on mindclarityhub.com/the-power-of-clarity/ at 375px: 14 anchors contained a
that wpautop injected. The live backstop lists classes - a.cta-animate br, a.affiliate-cta br, .wp-element-button br, .elementor-button br, ... - which fixes the seven CTAs that carry a class and misses the seven that do not. The ones it misses are the affiliate IMAGE links ("Boost focus with nootropics", "Sleep deeper tonight" and the rest): their markup is
, so the stray break pushes the image down and inflates the link box. Matching on POSITION instead of class closes the gap permanently and needs no maintenance as new blocks are added. A
as the first or last child of a link is never intentional - it is always wpautop - whereas a
BETWEEN two lines of link text can be deliberate, and this rule deliberately leaves that one alone. This only hides; it cannot alter markup or break a link. -------------------------------------------------------------------------------------------- */ a > br:first-child, a > br:last-child, button > br:first-child, button > br:last-child { display: none !important; } /* -------------------------------------------------------------------------------------------- 4. AUTO ADS SAT FLUSH TO THE LEFT EDGE WITH A 20px GAP ON THE RIGHT (MOBILE ONLY). Measured 2026-10-09 on mindclarityhub.com/focus-in-an-open-plan-office/ at a 375px viewport, on all eight in-article slots. Google's Auto Ads writes an inline style that asks for a full-bleed unit: width: 375px; margin: auto auto auto -10px; The -10px pulls the unit out of the article column's 10px padding so a 375px ad can reach both screen edges. But the unit never gets to 375px - something clamps it to the column's 355px - while the -10px offset still applies. Net effect, measured: the ad renders at x 0 -> 355 inside a column that runs 10 -> 365. Flush against the left edge, 20px of white on the right. That asymmetry is what reads as "not centered" and "cut off on one side". WHY max-width AND auto MARGINS, AND NOT margin-left: 0 Zeroing the margin fixes today's case (the ad is exactly column width, so 0 and auto are identical) but would break the case Google is actually coding for: if a unit ever does render at its full 375px, margin-left:0 would place it at 10 -> 385 and push 10px off the right of a 375px screen. max-width:100% keeps the unit inside the column whatever width Google asks for, and auto margins then centre whatever width survives. No overflow is possible either way. Verified before and after on the same page load: every slot moved from 0 -> 355 to 10 -> 365, gutters 10px both sides, document.scrollWidth unchanged at 375 (no new horizontal scroll). NOT A DEFECT ON DESKTOP, AND NOT A DEFECT EVERYWHERE At 1440px the same page already centres correctly - 960px unit in a 1020px column, 30px each side - because Google sets no negative margin there. garageplaybook's template has a full-width column, so its margin-left is already 0. This rule is inert in both cases: it only ever recentres a unit whose margins Google has offset. It changes where the ad sits, never whether it is shown, and it cannot shrink a unit below the width it already renders at. -------------------------------------------------------------------------------------------- */ .google-auto-placed ins.adsbygoogle { max-width: 100% !important; margin-left: auto !important; margin-right: auto !important; } /* -------------------------------------------------------------------------------------------- 5. BOOK-PAGE CTA LABELS WERE BLUE-ON-BLUE: CONTRAST 1.03:1. Reported by the owner 2026-10-09 as "almost transparent on the blue buttons", on every single book page. Measured on mindclarityhub.com/zen-in-the-digital-jungle/ at 375px: "Buy on Amazon" text rgb(81,105,168) on rgb(37,99,235) contrast 1.03:1 "Browse all books" text rgb(81,105,168) on rgb(30,41,59) 1.03:1 is the same class of defect as the 1.00:1 pills in this library's design/03 - the label is in the DOM, readable by a screen reader and by Google, and invisible to a human. WHAT MAKES THIS ONE DIFFERENT, AND WHY THE OBVIOUS FIX FAILED The buttons already carry the right colour inline: style="background:#2563eb;color:#fff". The CSSOM agrees - element.style.color reads rgb(255,255,255) - and yet the computed colour is rgb(81,105,168), the theme's link blue. Something outranks an inline declaration, which should be almost impossible. Everything that normally explains it was checked and ruled out: no !important colour rule anywhere (0 found across all 76 stylesheets) no animation, no transition (animation-name none, transition-duration 0s) no -webkit-text-fill-color override (reports the same value, so it is a symptom) not :visited (element does not match it, no :visited colour rules) Adding `color:#fff !important` on the element did NOT win either - and a probe proved the rule was applying, because `outline:3px solid lime !important` in the same block took effect while `color` did not. The cause is therefore still unidentified and is NOT claimed here. What is established by experiment is the remedy: qualifying the selector with :link and :visited wins where plain !important does not. WHY THIS SELECTOR IS SAFE It matches only anchors whose own inline style already declares color:#fff, and all it does is make that declaration effective. It cannot change the colour of any element that did not ask to be white, so it cannot create a new contrast failure anywhere on the fleet. Resulting contrast: #fff on #2563eb is 5.17:1, #fff on #1e293b is 14.63:1. Both pass AA. Verified on the live page: all four buttons rgb(255,255,255), and legible in a screenshot. PREFIXED html body, AND THAT PREFIX IS THE WHOLE FIX 0.2.5 shipped this rule without it and did nothing. The stylesheet loaded, the rule was in the CSSOM with its !important intact - verified by reading document.styleSheets on the live page - and the colour still computed to rgb(81,105,168). The competing declaration simply comes LATER in the cascade, and between two !important rules of equal specificity the later one wins. Proved by experiment rather than by reading, because two attempts to find the competing rule by scanning stylesheets both returned zero and both were wrong - getPropertyPriority reported no priority for a rule whose own cssText contained !important. So the question was settled the other way round: inject the high-specificity rule FIRST in , the worst possible document order, and see whether it still wins. It did - white - and removing it reverted the button to blue. html body takes the selector to (0,2,3) and makes it independent of load order. -------------------------------------------------------------------------------------------- */ html body a[style*="color:#fff"]:link, html body a[style*="color:#fff"]:visited, html body a[style*="color: #fff"]:link, html body a[style*="color: #fff"]:visited, html body a[style*="color:#ffffff"]:link, html body a[style*="color:#ffffff"]:visited, html body a[style*="color: #ffffff"]:link, html body a[style*="color: #ffffff"]:visited { color: #ffffff !important; -webkit-text-fill-color: #ffffff !important; }