/* Hand-written overrides for this migration.
 *
 * DELIBERATELY OUTSIDE site/public/styles/ (gotcha 49): tools/port-css.mjs owns
 * that directory and clears its own hashed outputs on every run, so a hand-written
 * sheet placed there is deleted by the next port with no error anywhere — on one
 * site that silently removed the sheet that hides the inactive device bands, and
 * all three headers then rendered at every width.
 *
 * Keep this file minimal. Anything that can come from the ported cascade should.
 */

/* The honeypot. Positioned off-screen rather than display:none — bots skip
 * obviously-hidden fields, and taking it out of flow means it costs no layout,
 * which the pixel gate would otherwise measure. */
.mg-hp {
  position: absolute !important;
  left: -9999px !important;
  top: auto !important;
  width: 1px !important;
  height: 1px !important;
  overflow: hidden !important;
}

/* SPECIFICITY NOTE — read before editing any rule below.
 *
 * Duda emits a per-widget rule for EVERY widget on the site, shaped
 *
 *     #dm .dmBody div.u_1213107879 { display: block !important }
 *
 * That is specificity (1,2,1) and it is `!important`. A hide written as a plain
 * `.mg-only-t { display:none !important }` is (0,1,0), so `!important` on both
 * sides means SPECIFICITY decides and Duda's rule wins — the element stays
 * visible and nothing in the console says so.
 *
 * Measured: with the plain selector, /blog rendered all THREE per-device widget
 * copies at once — 30 cards against live's 10, document height 7640px against
 * live's 3548px, and the gate scored 59.4%.
 *
 * So every gate below repeats its class three times behind `#dm`, giving (1,3,0),
 * which outranks (1,2,1) on class count without relying on source order. Do not
 * "tidy" the repetition away.
 */

/* Blog index: /blog serves 10 of 65 posts and pages the rest from Duda's backend,
 * which we do not have. All 65 ship; runtime.js shows one page of 10 at a time. */
#dm .mg-blog-hidden.mg-blog-hidden.mg-blog-hidden {
  display: none !important;
}

/* PER-DEVICE WIDGET FORKS.
 *
 * Duda builds .dmPhotoGallery and .mainBlog client-side and the three device
 * documents genuinely differ, so build-pages.py emits each widget three times and
 * stamps the copies mg-only-d / mg-only-t / mg-only-m. Without these rules ALL
 * THREE render at every width — which is exactly what the first gate run showed:
 * / came back at 77% with a +10458px height delta and /blog at 62% with +10150,
 * both of them simply the same widget painted three times over.
 *
 * The band boundaries are Duda's own, read out of the ported cascade: mobile
 * <=767, tablet 768-1024, desktop >=1025.
 *
 * These hide rather than remove, deliberately — the elements stay in the document
 * so the runtime can still address them, and display:none costs no layout.
 *
 * Only the INACTIVE bands are hidden, inside the media queries. The active band is
 * never touched, so it keeps whatever `display` the ported cascade gives it — an
 * earlier version hid all three and restored one with `display: revert`, which
 * reverts past the author cascade to the UA default and would have replaced the
 * widget's real display value with a plain `block`. */
@media (max-width: 767px) {
  #dm .mg-only-d.mg-only-d.mg-only-d,
  #dm .mg-only-t.mg-only-t.mg-only-t {
    display: none !important;
  }
}

@media (min-width: 768px) and (max-width: 1024px) {
  #dm .mg-only-d.mg-only-d.mg-only-d,
  #dm .mg-only-m.mg-only-m.mg-only-m {
    display: none !important;
  }
}

@media (min-width: 1025px) {
  #dm .mg-only-t.mg-only-t.mg-only-t,
  #dm .mg-only-m.mg-only-m.mg-only-m {
    display: none !important;
  }
}

/* ---------------------------------------------------------------------------
 * DRAWER APPEARANCE — measured overrides, and the only new layout CSS this
 * migration writes.
 *
 * The ported cascade's generic `.layout-drawer` rule wins here where live has
 * something more specific, so both drawers came out the wrong WIDTH and the
 * wrong COLOUR. None of it is visible to the pixel gate: the drawers are closed
 * in every capture, parked off-screen, so the pages score 0.000% either way.
 * Found by opening them with a real click and reading the computed styles.
 *
 * ALL VALUES MEASURED OFF LIVE, at several widths each, so the rule is derived
 * rather than guessed (tools/probe-drawer-width.mjs, tools/probe-mobile-drawer.mjs):
 *
 *   TABLET  #hamburger-drawer          live 384px at viewport 768 / 900 / 1000
 *                                      -> constant, so NOT device-relative;
 *                                         exactly 40% of the 960px canvas = 40vw
 *                                      ported sheet gave 75vw = 720px
 *
 *   MOBILE  #mobile-hamburger-drawer   live 256 / 300 / 340 / 480px at
 *                                      viewport 320 / 375 / 425 / 600
 *                                      -> a clean 0.80 ratio at every width = 80vw
 *                                      ported sheet gave 75vw
 *
 *   BOTH    background-color           live rgb(39, 94, 176)  (the brand blue)
 *                                      ported sheet gave rgb(255, 255, 255)
 *
 * Taking three or four measurements matters: at 768 alone, "40% of the canvas"
 * and "50% of the viewport" are the same number, and one data point cannot tell
 * them apart.
 * ------------------------------------------------------------------------- */
@media (min-width: 768px) and (max-width: 1024px) {
  #dm #hamburger-drawer.layout-drawer,
  #dm #hamburger-drawer.layout-drawer[data-origin="side"] {
    width: 40vw !important;
    background-color: rgb(39, 94, 176) !important;
  }
}

@media (max-width: 767px) {
  #dm #mobile-hamburger-drawer.layout-drawer,
  #dm #mobile-hamburger-drawer.layout-drawer[data-origin="side"] {
    width: 80vw !important;
    background-color: rgb(39, 94, 176) !important;
  }
}

/* ---------------------------------------------------------------------------
 * MOBILE DRAWER LOGO — measured override.
 *
 * The logo inside #mobile-hamburger-drawer scales with the drawer in the ported
 * cascade, so widening the drawer to live's 80vw (above) also blew the logo up.
 * Live pins it instead:
 *
 *     live  190x64 at viewport 375 / 640 / 641   (constant -> a fixed size)
 *     build 270x90 at 375, 483x162 at 641        (scaling with the drawer)
 *
 * The source file is only 230x77, so ours was rendering it at up to 2.1x — a
 * visibly soft logo. `check-upscale.mjs` reported exactly this as a RESOLUTION
 * SHORTFALL ("x2.099 ... renders 482.8x161.6 from a real 230x77 file"), and
 * pinning to live's size resolves the upscale finding and the fidelity gap in
 * one change.
 *
 * INVISIBLE TO THE PIXEL GATE, and correctly so: the element lives inside the
 * CLOSED drawer, which is translated off-screen (measured x = -245 live, -285
 * build), so `/` scores 0.000% at 375 either way. Note `offsetParent` is NOT null
 * for it — a probe that resolves "the visible copy" that way still lands on an
 * element no visitor can see until the menu is opened.
 *
 * The TABLET header logo needs no override: measured 220x74 at x=407 on both
 * sides at 768, matching exactly.
 * ------------------------------------------------------------------------- */
@media (max-width: 767px) {
  #dm #mobile-hamburger-drawer .imageWidget img,
  #dm #mobile-hamburger-drawer img {
    width: 190px !important;
    height: auto !important;
    max-width: 190px !important;
  }
}