/* ---------------------------------------------------------------------------
   Contain the hamburger menu to a corner panel.

   Esotera opens #mobile-menu as position:fixed / inset:0 / 100%x100% — a full
   viewport takeover. That is the right pattern on a phone, so below 768px this
   file changes nothing. At tablet and desktop widths it becomes an anchored
   dropdown panel in the top-right corner instead.

   Selectors are written as `nav#mobile-menu` to match the theme's own
   specificity (element+id), which plain `#mobile-menu` loses to.
   Scoped entirely to the menu; no other element is affected.
   --------------------------------------------------------------------------- */

@media screen and (min-width: 768px) {

  nav#mobile-menu {
    top: 92px;
    right: 26px;
    bottom: auto;
    left: auto;
    width: 330px;
    max-width: calc(100vw - 52px);
    height: auto;
    max-height: calc(100vh - 130px);
    padding: 14px 0 18px;
    line-height: 1.5;
    border-radius: 12px;
    box-shadow: 0 18px 48px rgba(22, 37, 33, 0.18),
                0 2px  8px rgba(22, 37, 33, 0.10);
    overflow-y: auto;
    overscroll-behavior: contain;
  }

  /* theme centres this at 80%/max 400px with a 10em top margin */
  nav#mobile-menu > div {
    width: auto;
    max-width: none;
    margin: 0;
  }

  /* theme spaces rows at 1.75em for a full-screen list — far too airy here */
  nav#mobile-menu ul li {
    margin: 0;
  }

  nav#mobile-menu ul li a {
    display: block;
    padding: 9px 20px;
  }

  /* search field spans the viewport by default */
  nav#mobile-menu .searchform,
  nav#mobile-menu form {
    width: auto;
    margin: 0 14px 10px;
  }

  nav#mobile-menu .searchform input,
  nav#mobile-menu form input[type="text"],
  nav#mobile-menu form input[type="search"] {
    box-sizing: border-box;
    width: 100%;
  }

  /* close button: viewport corner -> panel corner */
  nav#mobile-menu #nav-cancel {
    top: 2px;
    right: 2px;
    padding: 10px 14px;
    font-size: 18px;
  }

  /* submenus expand inside the panel */
  nav#mobile-menu .sub-menu,
  nav#mobile-menu .children {
    margin: 0;
    padding-left: 0;
  }

  nav#mobile-menu .sub-menu li a,
  nav#mobile-menu .children li a {
    padding-left: 36px;
  }

  /* The theme slides the whole page 75px left to reveal the full-screen menu
     (#site-wrapper.is-active { left:-75px !important }). Harmless when an
     overlay covers everything; jarring when the menu is a small corner panel.
     Needs !important to beat the theme's own. */
  #site-wrapper.is-active,
  .site-header-bottom-fixed.is-active {
    left: 0 !important;
  }

  /* #bmobile repeats the logo + tagline, absolutely positioned at top:0 of the
     menu — inside a panel it lands on top of the links. The real logo is still
     visible in the header behind the panel, so this is pure duplication. */
  nav#mobile-menu #bmobile {
    display: none;
  }

  /* The search row is position:absolute (top:57.6px) so it floats over the
     links once the panel is small. Put it back in the flow. */
  nav#mobile-menu li.menu-main-search {
    position: static;
    width: auto;
    margin: 6px 0 0;
    padding: 0 14px;
  }

  /* an inline search-icon <a> sits before the form and pushes it 40px right,
     overflowing the panel. The form is already visible, so the toggle is
     redundant here. */
  nav#mobile-menu li.menu-main-search > a {
    display: none;
  }

  /* the input is floated, so .searchform computes to height:0 and the field
     escapes below its row, leaving a gap. flow-root contains it. */
  nav#mobile-menu li.menu-main-search .searchform {
    display: flow-root;
    width: 100%;
    margin: 0;
  }

  nav#mobile-menu li.menu-main-search .searchform input {
    box-sizing: border-box;
    width: 100%;
  }

  /* submenu chevron sits 14px past the panel's right edge — anchor it inside
     (the theme already sets position:relative on the li) */
  nav#mobile-menu .dropdown-toggle {
    position: absolute;
    top: 0;
    right: 10px;
    margin: 0;
  }
}

/* ---------------------------------------------------------------------------
   Remove dead search UI.

   WordPress search needs a PHP backend. On static hosting every one of these
   returns nothing, so they are broken controls rather than features. Three
   instances per page:

     li.menu-main-search    - in #mobile-nav (the panel) and in #prime_nav
     li.menu-footer-search  - in the footer menu

   Hidden rather than stripped from the markup, so restoring them is a one-line
   change if search is ever reinstated (Pagefind would do it properly on static
   output).
   --------------------------------------------------------------------------- */

li.menu-main-search,
li.menu-footer-search {
  display: none !important;
}

/* ---------------------------------------------------------------------------
   Fix inline PDF embeds.

   The theme runs FitVids, which wraps embedded media in
   .fluid-width-video-wrapper and injects an inline stylesheet:

     .fluid-width-video-wrapper           { width:100%; position:relative; padding:0 }
     .fluid-width-video-wrapper object    { position:absolute; top:0; left:0; ... }

   FitVids is built for video iframes: it normally sets padding-top to the
   aspect ratio so the absolutely-positioned child has room. A PDF <object> has
   no aspect ratio, so padding stays 0, the wrapper collapses to 0 height, and
   the 600px viewer overflows on top of the download button and the content
   below it.

   Putting the object back in normal flow gives the wrapper its height back.
   Specificity (0,2,1) beats FitVids' (0,1,1), so this wins despite their
   stylesheet being injected later.
   --------------------------------------------------------------------------- */

.wp-block-file .fluid-width-video-wrapper {
  height: auto;
  max-height: none;
}

.wp-block-file .fluid-width-video-wrapper > object.wp-block-file__embed {
  /* <object> is inline by default; absolute positioning had been blockifying
     it, so returning it to flow needs display:block or it collapses to 0 */
  display: block;
  position: relative !important;
  top: auto !important;
  left: auto !important;
  width: 100%;
  height: 600px;
}

/* ---------------------------------------------------------------------------
   Portfolio slide galleries: full-width showcase, not a thumbnail stack.

   The articles embed presentation decks as wp:gallery blocks (9-21 slides).
   WordPress's gallery CSS sizes each figure for a 3-across grid
   (width: calc(33.33% - gap)) and relies on the container being flex. Here the
   container computes to display:block, so the figures keep their one-third
   width but stack vertically -- a 339px column of thumbnails running 4000px
   down the page, with the slides far too small to read.

   These decks are the showcase content of the page, so each slide gets the
   full content width with real breathing room between them.

   WordPress inflates its gallery selectors with :not(#individual-image), which
   adds an ID to the specificity (1,1,1). Class-only overrides lose to that no
   matter how many classes they chain, so the same trick is used here.

   Source images are 960x540 (the originals -- no larger version exists), so at
   ~1048px they upscale about 9%, which is not noticeable on slide artwork.
   --------------------------------------------------------------------------- */

.single-jetpack-portfolio .entry-content .wp-block-gallery.has-nested-images {
  display: block;
  margin: 2.5em 0;
  gap: 0;
}

.single-jetpack-portfolio .entry-content .wp-block-gallery.has-nested-images > figure.wp-block-image:not(#individual-image) {
  display: block;
  width: 100%;
  max-width: none;
  margin: 0 0 2.25em;
}

.single-jetpack-portfolio .entry-content .wp-block-gallery.has-nested-images > figure.wp-block-image:not(#individual-image):last-child {
  margin-bottom: 0;
}

/* .is-cropped forces equal-height object-fit crops for grid layouts */
.single-jetpack-portfolio .entry-content .wp-block-gallery.has-nested-images > figure.wp-block-image:not(#individual-image) img {
  display: block;
  width: 100%;
  height: auto;
  object-fit: initial;
  border-radius: 6px;
  box-shadow: 0 2px 10px rgba(22, 37, 33, 0.10);
}

/* ---------------------------------------------------------------------------
   PDF download button.

   The theme ships no .wp-block-file rules and its button reset strips
   WordPress's default padding, leaving the "Download" pill at padding:0 —
   a 54x22 chip with the label pressed against its own edges.

   Sized to match the theme's own in-content button convention
   (.wp-block-button__link: padding .5em 1.5em, border-radius 100px), and given
   room to breathe under the 600px viewer above it.
   --------------------------------------------------------------------------- */

.wp-block-file .wp-block-file__button {
  display: inline-block;
  padding: 0.55em 1.5em;
  border-radius: 100px;
  font-size: 0.9em;
  line-height: 1.6;
  margin-left: 0.75em;
  text-decoration: none;
  transition: opacity 0.2s ease, transform 0.2s ease;
}

.wp-block-file .wp-block-file__button:hover,
.wp-block-file .wp-block-file__button:focus {
  opacity: 0.88;
}

/* separate the filename + download row from the viewer above it */
.wp-block-file .fluid-width-video-wrapper {
  margin-bottom: 1.25em;
}

/* ---------------------------------------------------------------------------
   Portfolio date pill.

   single-jetpack-portfolio.php fills .entry-meta-container with three rows:
   the date, project types (jetpack-portfolio-type) and tags
   (jetpack-portfolio-tag). These articles have no taxonomy terms assigned --
   the same emptiness that made the theme print "Array" on the listing pages --
   so the theme's 55%-wide, 3-row pill ends up holding a single left-aligned
   line of light grey text. It reads as a mistake rather than a design element.

   Shrink-wrapped to its content, centred, and given enough contrast to be
   legible over the artwork behind it.
   --------------------------------------------------------------------------- */

.single article.jetpack-portfolio .entry-meta-container {
  width: auto;
  max-width: 80%;
  background-color: rgba(255, 255, 255, 0.85);
  backdrop-filter: saturate(140%) blur(2px);
  -webkit-backdrop-filter: saturate(140%) blur(2px);
  box-shadow: 0 2px 10px rgba(22, 37, 33, 0.10);
}

.single article.jetpack-portfolio .entry-meta {
  padding: 0.5em 1.6em;
  text-align: center;
}

.single article.jetpack-portfolio .entry-meta > span {
  font-size: 0.82em;
  letter-spacing: 0.06em;
  text-transform: uppercase;
  color: rgb(22, 37, 33);
}

/* Date pill sits bottom-right as a footnote rather than centred under the
   artwork. The theme centres it with left:0; right:0; margin:0 auto. */
.single article.jetpack-portfolio .entry-meta-container {
  left: auto;
  right: 1.5em;
  bottom: 1.5em;
  margin: 0;
}

/* the hero is only ~300px wide on a phone, where the same pill reads as 38% of
   the artwork; scale it back so it stays a footnote at every size */
@media screen and (max-width: 600px) {
  .single article.jetpack-portfolio .entry-meta-container {
    right: 0.75em;
    bottom: 0.75em;
  }
  .single article.jetpack-portfolio .entry-meta {
    padding: 0.35em 1em;
  }
  .single article.jetpack-portfolio .entry-meta > span {
    font-size: 0.7em;
  }
}

/* ---------------------------------------------------------------------------
   Top-nav dropdown was clipped by the right edge of the page.

   The primary nav sits hard right (body.esotera-menu-right), and the theme
   opens submenus from their parent's LEFT edge (#access ul ul { left: 0 }).
   For "More" — the rightmost item with children — that put the 168px dropdown
   at x=1308 on a 1440px viewport, running 36px off screen.

   Anchoring top-level dropdowns to the right edge of their parent is the
   correct behaviour for a right-aligned menu: they now open inward.
   --------------------------------------------------------------------------- */

#access #prime_nav > li.menu-item-has-children > .sub-menu {
  left: auto;
  right: 0;
}

/* ---------------------------------------------------------------------------
   Contact page: direct email instead of the WPForms form.

   The form needed PHP and could never submit on static hosting. It also asked
   for nothing a reply-to would not carry, and the address is already published
   sitewide, so it was not shielding anything from scrapers.

   The address is set as readable, selectable text rather than only a mailto
   link — that is the part that matters. A bare mailto does nothing for someone
   reading in webmail with no mail client configured, and they leave without
   you ever knowing they tried.
   --------------------------------------------------------------------------- */

.lmn-direct-contact {
  padding: 0.25em 0 1em;
}

.lmn-direct-lead {
  margin: 0 0 0.5em;
  font-size: 1.05em;
}

.lmn-direct-address {
  margin: 0 0 1.15em;
  font-size: 1.5em;
  line-height: 1.35;
  word-break: break-word;
}

.lmn-direct-address a {
  text-decoration: none;
  border-bottom: 2px solid currentColor;
  padding-bottom: 3px;
  transition: opacity 0.2s ease;
}

.lmn-direct-address a:hover,
.lmn-direct-address a:focus {
  opacity: 0.75;
}

.lmn-direct-note {
  margin: 0;
  max-width: 34em;
  font-size: 0.92em;
  line-height: 1.7;
  opacity: 0.78;
}

@media screen and (max-width: 600px) {
  .lmn-direct-address { font-size: 1.28em; }
}