/* The ONLY hand-written CSS in this build. * * Duda serves three HTML documents and each one contains just its own header, * so it never needs to hide the others. This build serves one document that * carries both header variants — the standard bar for tablet/desktop and the * hamburger bar, drawer and overlay for mobile — so exactly one of them has to * be switched off at each width. That is all these rules do; no layout, * spacing, colour or type value is set here. * * Loaded last so it wins over the ported bundles. */ /* Tablet and desktop: the mobile chrome is not part of those documents. */ @media (min-width: 768px) { #site_content > .p_hfcontainer, #layout-drawer-overlay, #hamburger-header-container, #layout-drawer-hamburger, #dmBackToTop { display: none !important; } } /* Mobile: the standard header is not part of that document. */ @media (max-width: 767px) { .dmHeaderContainer { display: none !important; } } /* Duda's mobile header is position:fixed, and it clears it by putting a * top margin equal to the header height on .site_content: * * .runtime-module-container[dmtemplateid*=amburger] .site_content{margin-top:59px} * * That element carries the union of both documents' dmtemplateid values here, * so the rule would otherwise also fire at tablet and desktop, where the * mobile header is hidden and there is nothing to clear. */ @media (min-width: 768px) { #site_content > .site_content { margin-top: 0; } } /* The reCAPTCHA rules that used to live here are gone. * * They reserved the widget's measured footprint (78px, 144px below 768) so the * page below the form sat at the original's offset. The widget itself is now * removed rather than reproduced — Duda's site key cannot validate on the * client's domain — so there is nothing to reserve space for, and the form * closes up on its own field spacing. See MIGRATION-NOTES.md §5. * * Duda's own ported .g-recaptcha rules are deliberately left in the ported * stylesheets. They match nothing now, and pruning ported CSS is against the * project rule. */ /* The .fb-comments min-height that used to be here is gone. * * Every blog post ends with a .fb-comments block. When this build was made, * Facebook's SDK resolved it to a 30px-tall element on the live site while ours * collapsed to 0, pulling the footer up 30px on every post — so 30px was * reserved to match. * * That is no longer true. Measured across all seven posts at 1440, live now * renders it at 0 (6 of 7 read cleanly, the seventh timed out), so the reserved * 30px had become the mismatch: +30px on every post, worth 6.8-11.4% on the two * posts with no photo gallery below it. * * Third-party embeds move on their own schedule, so the gate also passes * .fb-comments to --collapse: display:none on BOTH sides, which is immune to * whichever way Facebook goes next. Reserving a fixed height for someone else's * widget is what created this problem twice. */ /* Duda animates the drawer open by adding a class to ; reproduce the two * states it toggles so the hamburger works without Duda's runtime. */ body.dmDrawerOpen #mobile-hamburger-drawer { transform: translateX(0) !important; } body.dmDrawerOpen #layout-drawer-overlay { opacity: 1; pointer-events: auto; } #layout-drawer-overlay { opacity: 0; pointer-events: none; transition: opacity 0.3s ease; }