/*
 * Stoneflower mobile retrofit.
 * Every responsive rule lives here — style.css is deliberately untouched
 * (it drifts on the dev server; a separate file survives an overwrite).
 * Enqueued after style.css with a dependency, so equal-specificity rules win.
 * Above 980px this file must have zero visual effect. The one unscoped block
 * below reproduces verbatim the styles lifted from #header-new's former
 * inline style attribute in header.php, so the phone rules can override
 * them without !important.
 */

#header-new {
	width: 100%;
	height: 100px;
	background-color: rgba(255, 255, 255, 0.85);
	display: flex;
	border-radius: 15px 15px 0 0;
}

/* ≤980px: the fixed 940px frame becomes fluid. Still two columns. */
@media (max-width: 980px) {
	#wrapper,
	#main,
	#branding,
	#colophon,
	#access .menu-header,
	div.menu {
		width: auto;
	}

	#wrapper {
		padding-left: 20px;
		padding-right: 20px;
	}

	/* style.css:1510 floats #access, and that float is the only thing
	   containing the floated menu items (#access .menu-header li,
	   style.css:1541). Dropping the float for a full-width box loses the
	   containment: #access collapses to 0px tall and its green background
	   paints nothing, so the menu text sits straight on the page
	   background (measured at 900px: #access height 0, items 38px).
	   flow-root restores containment without overflow: hidden, which
	   would clip the absolutely-positioned hover dropdowns (#access ul ul,
	   style.css:1559). */
	#access {
		float: none;
		width: auto;
		display: flow-root;
	}

	img,
	svg,
	iframe {
		max-width: 100%;
		height: auto;
	}
}

/* ≤800px: single column, readable type. */
@media (max-width: 800px) {
	/* style.css:669 sets margin-top: 25px; match the 12px side padding
	 * so the top and side gutters feel symmetric. */
	#wrapper {
		margin-top: 12px;
		padding-left: 12px;
		padding-right: 12px;
	}

	/* Owner nit: align the wordmark's left edge with the content column's
	 * own text below it. Measured live at 390px: #content h2 ("Aktuellt")
	 * left = 27px (#wrapper's 12px padding + #content's own 15px padding,
	 * confirmed via getBoundingClientRect, not assumed). #header-new
	 * itself starts flush at #wrapper's inner edge (left = 12px), so
	 * margin-left: 15px lands the wordmark at 12 + 15 = 27, matching.
	 * Applies to both .js and .no-js -- the wordmark's role and position
	 * don't depend on script state, unlike the hamburger/logo swap below.
	 * !important: #header-wordmark carries an inline
	 * style="margin-left: 35px" (header.php), which any external rule
	 * loses to without it. */
	#header-wordmark {
		margin-left: 15px !important;
	}

	/* Owner addition: guarantee visible space between the wordmark and
	 * whatever sits in #header-new's right slot (button or, for .no-js,
	 * the round logo). Measured live: at both 390px and 320px the
	 * wordmark image's rendered width exactly filled #header-wordmark's
	 * full flex-grown width, right up against the right slot -- zero
	 * gap. Root cause: the global `img { max-width: 100% }` rule (above,
	 * ≤980px block) constrains the image to 100% of #header-wordmark's
	 * own width, and that width is however much #header-new's flex-grow
	 * leaves it, with nothing reserving a margin. column-gap on the flex
	 * container is accounted for before flex-grow distributes remaining
	 * space, so it shrinks #header-wordmark's own allotment first --
	 * the image (100% of that, per the existing rule) then naturally
	 * renders narrower, opening real space rather than being clipped or
	 * pushed under the button. No .js scope: applies to both states,
	 * like the wordmark's own margin above. */
	#header-new {
		column-gap: 12px;
	}

	/* #container (float:left; margin:0 -240px 0 0; width:100%; in style.css,
	 * present in every template) still floats here even though #content's
	 * own margin is reset above. #primary inherits overflow:hidden from
	 * style.css, so unless #container's float is also cleared, #primary's
	 * auto width shrink-wraps into the 240px gap #container's negative
	 * margin leaves beside it, instead of dropping to full width below
	 * content. */
	#container {
		float: none;
		width: auto;
		margin: 0;
	}

	#content {
		margin: 0;
	}

	/* Copy sat flush against #wrapper's inner edges with no gutter of
	 * its own; give the content column and both sidebar columns side
	 * padding. #secondary is dormant on this site today (no active widget
	 * area renders there), but style.css treats it identically to #primary
	 * (same float/width rule at style.css:269), so it gets the same gutter
	 * for parity if it's ever used. */
	#content,
	#primary,
	#secondary {
		padding-left: 15px;
		padding-right: 15px;
	}

	/* A word wider than its column is silently truncated here, not
	 * scrolled: #main carries overflow:hidden (style.css:1713), so the
	 * overflow never reaches the viewport and a scrollWidth check on the
	 * document sees nothing wrong. The DSK page's H2
	 * "Distriktssköterskemottagning/diabetessköterska" is one 507px token
	 * in a 306px column at 375px, and compounds that long are ordinary
	 * Swedish, so this will recur. No break offers itself inside such a
	 * token -- browsers do not break after the "/" either -- hence a
	 * last-resort one. "break-word" rather than "anywhere": it acts only
	 * when a word cannot fit on a line of its own, and leaves min-content
	 * sizing untouched. Set on the three columns, not on the headings,
	 * because the property inherits and body copy can carry long words
	 * too (URLs, e-mail addresses). */
	#content,
	#primary,
	#secondary {
		overflow-wrap: break-word;
	}

	#primary,
	#secondary {
		float: none;
		width: auto;
	}

	/* style.css:1720 (`#main li { list-style: disc; }`, unscoped by any
	 * media query) applies at every width, but the "outside" marker is
	 * invisible on desktop by accident, not by design: #primary/#secondary
	 * have overflow:hidden (style.css) and zero left padding there, so the
	 * marker -- rendered outside the li's own box -- gets clipped. Once
	 * this file gives #primary/#secondary a 15px left gutter above, there
	 * is room for the marker to render, and it becomes visible. Neither
	 * #primary nor #secondary had bullets before this file's changes, so
	 * restore that: descendant selector (not just the top-level .xoxo)
	 * to also catch any nested widget lists. */
	#primary li,
	#secondary li {
		list-style: none;
	}

	/* Sidebar image widgets (1177 badge, opening-hours/location SVGs) sit
	 * at their inline ~200px width, about half the mobile screen. Target
	 * the shared structural pattern -- an <a> whose only child is an img
	 * -- rather than the widgets' auto-numbered block ids, which
	 * renumber if widgets are reordered; no shared class covers exactly
	 * these three without also matching the heading widget or footer
	 * widgets.
	 *
	 * Two separate things pin these images narrow:
	 * - style.css:4396 floats every img inside #main right, and a
	 *   percentage width on a floated replaced element can't resolve
	 *   against an indefinite containing block -- it silently falls back
	 *   to the image's intrinsic size. Float must be cleared on the img
	 *   itself.
	 * - WordPress core's block-library CSS makes `.wp-block-image a`
	 *   (two of the three widgets) `display: inline-block` with
	 *   `width: auto`, which shrink-wraps the anchor to the image's own
	 *   intrinsic width -- a circular dependency: the anchor's width
	 *   comes from the image's natural size, then the image's 100%
	 *   resolves against that same shrunken anchor. Forcing the anchor
	 *   to `display: block; width: 100%` breaks the circularity, sizing
	 *   it from the widget column instead. (The third widget's anchor
	 *   has no such wrapper and is plain `display: inline`, which
	 *   doesn't establish a containing block at all -- percentage
	 *   resolution already skips through it to the widget column, so it
	 *   rendered correctly before this rule; harmless to include here.)
	 *
	 * `display` and `width` on the anchor need no !important: this
	 * selector's specificity (#primary/#secondary ID + a + :has(img))
	 * already outranks core's `.wp-block-image a` and `#main img`, which
	 * aren't !important either. `float` and `margin-right` do need it:
	 * one of the three anchors also carries an inline `style="float:
	 * left; margin-right: 10px"` (the old two-column layout), and only
	 * !important in a stylesheet beats an inline style. */
	#primary a:has(> img),
	#secondary a:has(> img) {
		display: block;
		float: none !important;
		width: 100%;
		margin-right: 0 !important;
	}

	/* `float` needs no !important: `#main img { float: right; }` is
	 * weaker than this selector's specificity, and `.wp-block-image img`
	 * doesn't touch float at all. `width` still needs it, though: two of
	 * the three images carry their own inline `style="width:200px"`
	 * (separate from the anchor's inline style above) -- confirmed live
	 * that dropping !important here left those two stuck at 200px while
	 * the third (no inline width, just HTML width/height attributes,
	 * which any stylesheet rule outranks) rendered full width. `height`
	 * needs none: no inline height on any of the three, and it only
	 * needs to track the now-correct width via aspect ratio. */
	#primary a:has(> img) img,
	#secondary a:has(> img) img {
		float: none;
		width: 100% !important;
		height: auto;
	}

	/* Owner decision: the 1177 Vårdguiden image widget duplicates the
	 * sticky call bar's own permanent 1177 button (footer.php), and reads
	 * as too heavy at full width on phones. Hide it entirely under 800px;
	 * desktop keeps it.
	 *
	 * #block-17 is WordPress's auto-numbered widget-block id -- not
	 * stable if this widget is ever deleted and recreated. If this stops
	 * matching, re-identify it live: it's the `<li class="widget-
	 * container widget_block">` in #primary's ul.xoxo whose <a href>
	 * points at 1177.se and whose lone <img> is
	 * 1177-sociallogo-100x100.gif -- no figure/wp-block-image wrapper,
	 * unlike the other two sidebar image widgets (it predates that
	 * widget type). Full markup is documented in task-3-report.md,
	 * addendum "full-width sidebar widget images".
	 *
	 * No orphaned caption to worry about: downloaded and viewed the GIF
	 * directly -- "Förnya recept, avboka tid mm." is baked into the same
	 * flat raster image as the "1177 VÅRDGUIDEN" card, not a separate
	 * element in the DOM. Hiding this one <li> removes both at once. */
	#block-17 {
		display: none;
	}

	/* Block-editor columns (e.g. the mottagningar staff-photo pages) don't
	 * reflow. A column block whose "Stack on mobile" toggle was left off
	 * in the editor gets `is-not-stacked-on-mobile`, which WordPress
	 * core's block-library CSS keeps `flex-wrap: nowrap !important` on
	 * unconditionally, at every width -- so at 390px the 3 desktop
	 * columns stay 3 columns, squeezed to ~90px each.
	 *
	 * `.wp-block-columns` is already a flex container; give columns a
	 * flexible min-width and let flex-wrap do genuine responsive reflow
	 * instead of a hard single-column stack: as many columns as fit sit
	 * side by side, dropping a column per row as the viewport narrows, no
	 * extra breakpoint needed. 300px comfortably fits one portrait photo
	 * plus its caption; two 300px columns need roughly 620px+ of content
	 * width (so ~768px tablets get two per row, phones get one), three
	 * need the full ~900px+ desktop content width -- above this file's
	 * 800px breakpoint, so this block never has to arrange three.
	 *
	 * `flex-wrap` needs !important regardless of the selector's scope:
	 * core's own `.wp-block-columns.is-not-stacked-on-mobile` rule forces
	 * `nowrap` with !important too, and at equal (0,2,0) class
	 * specificity a plain override would lose the source-order tie --
	 * `#wp-block-columns-inline-css` is printed by wp_head() after this
	 * file's <link>. `#content` as an ancestor raises specificity past
	 * core's rule regardless of source order, so !important plus the
	 * ID anchor together are what win. Not scoped to `.is-not-stacked-
	 * on-mobile` -- ordinary columns already get `flex-wrap: wrap`
	 * unconditionally from core's own base rule, so repeating the same
	 * value there is a harmless no-op, and it saves a second selector.
	 *
	 * `flex` on the column itself needs no !important: core's matching
	 * rule for the `is-not-stacked-on-mobile` variant
	 * (`.wp-block-columns.is-not-stacked-on-mobile > .wp-block-column
	 * { flex-basis: 0; flex-grow: 1; }`) isn't !important, and
	 * `#content .wp-block-column` (ID-anchored) outranks it on
	 * specificity alone. For ordinary columns, core's stacking rule
	 * (`.wp-block-columns:not(.is-not-stacked-on-mobile) > .wp-block-
	 * column { flex-basis: 100% !important; }`) only applies at
	 * max-width: 781px, so it wins over this non-important rule and
	 * this rule is inert there -- fine, ordinary columns already stack
	 * correctly on their own below 782px. Above that, inside this
	 * file's own ≤800px breakpoint, core's rule no longer applies at
	 * all (782-800px is outside its max-width: 781px), so this rule is
	 * the one governing ordinary columns there and produces the
	 * intended reflow -- reachable live on the Om oss page (post 106),
	 * whose columns are ordinary (not is-not-stacked-on-mobile). */
	#content .wp-block-columns {
		flex-wrap: wrap !important;
	}

	#content .wp-block-column {
		flex: 1 1 300px;
	}

	/* Person-listing images (the mottagningar staff pages, e.g. /lakare/,
	 * /sjukgymnastik/) render at roughly half their column's width.
	 * Diagnosed live, same disease as the sidebar widget images (above):
	 * - The <img> itself carries an inline `style="width:auto;height:
	 *   225px"` (WordPress's image-resize UI writes this when an editor
	 *   drags a photo to a caption height). The fixed 225px height lets
	 *   width follow each photo's own aspect ratio -- different portraits
	 *   land at different, sub-column widths (~160-180px in a 321px
	 *   column). The figure itself is already full column width; it's
	 *   only the <img>'s own inline style doing this. Both `width` and
	 *   `height` are inline-set here (unlike the sidebar widgets, where
	 *   only `width` was), so both need !important to beat them --
	 *   core's own `.wp-block-image img { height: auto; max-width: 100%;
	 *   }` already agrees with the intent but loses to the inline style
	 *   the same way this file's rule would without !important.
	 * - The wrapping <a> (WordPress core's unscoped `.wp-block-image >
	 *   figure > a { display: inline-block; }`) shrink-wraps to the
	 *   img's own rendered size -- the same circular containing-block
	 *   trap as the sidebar widgets. No !important needed to fix it: this
	 *   selector's ID-anchored specificity already outranks core's
	 *   class-only rule. Kept at width: 100% (not 90%, see below) so the
	 *   image's own 90% below resolves against the full column, not an
	 *   already-narrowed anchor.
	 * - A third thing, found only by testing the 768px two-up layout, not
	 *   just 390px: style.css:2799 sets `#content img { max-width:
	 *   640px; width: auto; }` (a legacy desktop cap). `max-width` clamps
	 *   the rendered size independently of `width`, so `width: 90%
	 *   !important` alone doesn't remove it -- invisible at 390px, where
	 *   every column is well under 640px, but it clips the third
	 *   (wrapped, grown-to-699px) column's images at 768px. This
	 *   selector's added class already outranks `#content img` on
	 *   specificity, so no !important needed here either.
	 *
	 * Owner follow-up: full width read as too heavy; back the image down
	 * to 90% of the column, centred. `display: block` first -- `margin:
	 * auto` only centres a block-level box; an inline or inline-block
	 * element's auto margins compute to 0, not centring, and this <img>
	 * has no other display rule to fall back on. `float: none` too: this
	 * rule never needed it while the image was full width (a floated
	 * element's own width still fills 100% when explicitly given, so it
	 * looked identical to non-floated), but a floated box's auto margins
	 * always resolve to 0 regardless of specificity -- confirmed live
	 * that even forcing margin-left/right: auto with an inline
	 * !important still left the image flush right, not centred, until
	 * float was also cleared. No !important needed on display, the
	 * anchor's width, margin, or float: this selector's specificity
	 * clears every competing rule (the universal `img { margin: 0 }` reset and
	 * `#main img { float: right }` are both bare type/ID+type
	 * selectors), and nothing here fights an inline style the way the
	 * img's own width/height still do. */
	#content .wp-block-column a:has(> img) {
		display: block;
		width: 100%;
	}

	#content .wp-block-column img {
		display: block;
		float: none;
		max-width: 100%;
		width: 90% !important;
		height: auto !important;
		margin-left: auto;
		margin-right: auto;
	}

	/* 12px desktop base -> 16px; below 16px iOS zooms on input focus. */
	body,
	input,
	textarea {
		font-size: 16px;
		line-height: 1.5;
	}

	.widget-area {
		font-size: 16px;
	}

	/* The rule above sets font-size on #primary/#secondary themselves
	 * (the .widget-area DIV), but every piece of visible widget text
	 * sits inside a `.widget-container` <li>, and the site's own
	 * Customizer Additional CSS (wp-admin -> Customize -> Additional
	 * CSS, DB-stored in wp_posts as a custom_css post, rendered as
	 * `<style id="wp-custom-css">` -- admin-editable, invisible to git,
	 * may change without a code deploy) sets
	 * `.widget-area .widget-container { font-size: 12px; }` --
	 * specificity (0,2,0), beating the single-class rule above (0,1,0)
	 * regardless of source order. Confirmed live: the <li>s and their
	 * text (h2/p) computed 12px despite the rule above. #primary as an
	 * ID anchor (matching this file's convention elsewhere) outranks it
	 * outright -- no !important needed, this isn't an inline style.
	 * Scoped to #primary/#secondary specifically (not a bare
	 * `.widget-area .widget-container`), so it can't reach footer
	 * widgets or the call bar, which live in different DOM subtrees
	 * entirely; harmless on the two image widgets, which have no visible
	 * text to enlarge. */
	#primary .widget-container,
	#secondary .widget-container {
		font-size: 16px;
		line-height: 1.5;
	}

	#site-title {
		font-size: 24px;
	}

	#site-description {
		font-size: 16px;
	}

	/* style.css:4764 (`#footer center`, "GDUE sidfot adressrad") sets
	 * margin-top: -30px, tuned to tuck the address line under the
	 * desktop-width #colophon row. At single-column width that pulls it
	 * up into #site-info's own box. Neutralise it so the footer stacks
	 * without overlap. `margin-bottom` is new: `html body`'s
	 * padding-bottom (below, call bar section) reserves exactly the call
	 * bar's own height at the foot of the page, so the address/fax line
	 * sat flush against the bar's top edge with zero visible clearance.
	 * 16px of margin here pushes the page's natural content past that
	 * reserved space, opening breathing room above the bar. */
	#footer center {
		margin-top: 0;
		margin-bottom: 16px;
	}

	/* Owner nit: #site-info ("Stenblommans Vårdcentral") was left-aligned
	 * at single-column width, alone on its own full-width row -- no
	 * competing rule to beat here (style.css never sets its text-align),
	 * so the default computed to `start`. */
	#site-info {
		text-align: center;
	}
}

/* Menu toggle: lives in #header-new's #header-logo slot (the round logo
   hides, the button takes its place). Exists in the DOM at every width, but
   only ≤800px shows it. */
.menu-toggle {
	display: none;
}

/* ≤800px: hamburger opens a full-screen overlay with the whole menu tree
   already expanded -- no accordion. Owner-review superseded the earlier
   chevron design (spec decision 6c): tapping a parent link was ambiguous
   with a chevron present, and the chevrons themselves were easy to miss.
   Collapse rules stay scoped under .js so no-JS users keep getting the
   fully expanded stacked menu instead of no menu at all. */
@media (max-width: 800px) {
	/* !important: the anchor carries an inline style="display: flex; ..."
	   (header.php), which any external rule loses to without it. */
	.js #header-logo > a {
		display: none !important;
	}

	/* Owner nit: mirror the wordmark's new left offset on the right --
	   the toggle should sit the same distance from the viewport's right
	   edge as the wordmark sits from its left. With the round logo hidden
	   above, #header-logo's box shrink-wraps to just the button, so its
	   own margin-right directly controls the button's right edge.
	   Re-review caught a coordinate-frame bug in the first attempt here:
	   getBoundingClientRect() is relative to document.documentElement.
	   clientWidth (375 at 390px wide, in a harness with a reserved
	   scrollbar gutter), not window.innerWidth (390, includes that
	   gutter) -- margin-right: 0 measured against clientWidth left the
	   button only 12px from the true right edge (wrapper's 12px padding
	   + 0), not the 27px the wordmark sits at on the left. #header-new is
	   flush with #wrapper's padding-box on both sides, so the fix is the
	   same margin as the wordmark's: 15px lands the button at
	   wrapper-padding(12) + 15 = 27, matching. Scoped to .js only: for
	   .no-js there's no button, and the round logo's original 30px
	   margin-right should stay untouched. !important for the same reason
	   as the display:none above -- #header-logo carries an inline
	   style="margin-right: 30px". */
	.js #header-logo {
		margin-right: 15px !important;
	}

	/* Icon-only button: no text glyphs (☰/✕ render inconsistently across
	   fonts), a real three-bar icon instead, drawn with the child span and
	   its two pseudo-elements and morphed to an ✕ purely off the
	   aria-expanded attribute JS already sets -- no extra JS-driven class
	   needed for the animation. */
	.menu-toggle {
		display: flex;
		align-items: center;
		justify-content: center;
		box-sizing: border-box;
		width: 44px;
		height: 44px;
		border: 0;
		border-radius: 50%;
		background: #87c7b5;
		cursor: pointer;
		/* Positioned + z-index so the button paints above the overlay below
		   -- itself a positioned element, which would otherwise cover it
		   regardless of DOM order. */
		position: relative;
		z-index: 100001;
	}

	.menu-toggle-bars {
		position: relative;
		width: 20px;
		height: 2px;
		background: #2a2a2a;
		transition: background 0.2s ease;
	}

	.menu-toggle-bars::before,
	.menu-toggle-bars::after {
		content: "";
		position: absolute;
		left: 0;
		width: 20px;
		height: 2px;
		background: #2a2a2a;
		transition: top 0.2s ease, transform 0.2s ease;
	}

	.menu-toggle-bars::before {
		top: -7px;
	}

	.menu-toggle-bars::after {
		top: 7px;
	}

	/* Open state: middle bar fades out, top/bottom bars meet at centre and
	   rotate into an ✕. Keyed off aria-expanded, which the click handler
	   already sets -- no separate open/closed class needed on the button.
	   The circle's own #87c7b5 fill is byte-identical to the open-state
	   overlay's background (confirmed via getComputedStyle: both
	   rgb(135, 199, 181)), so without a border the circle was completely
	   invisible there, leaving the ✕ floating with no visible button.
	   Owner: closed state (on the near-white header strip, where the fill
	   already reads fine) should stay exactly as-is -- border only in the
	   open state, and as thin as it renders (1px). */
	.menu-toggle[aria-expanded="true"] {
		border: 1px solid #2a2a2a;
	}

	.menu-toggle[aria-expanded="true"] .menu-toggle-bars {
		background: transparent;
	}

	.menu-toggle[aria-expanded="true"] .menu-toggle-bars::before {
		top: 0;
		transform: rotate(45deg);
	}

	.menu-toggle[aria-expanded="true"] .menu-toggle-bars::after {
		top: 0;
		transform: rotate(-45deg);
	}

	.js #access .menu-header ul,
	.js #access div.menu ul {
		display: none;
	}

	/* Descendant selector, not `>` -- unhides every level at once, so
	   parents and children appear together. No accordion. */
	.js #access.menu-open .menu-header ul,
	.js #access.menu-open div.menu ul {
		display: block;
	}

	/* Full-screen overlay. z-index sits below the call bar's 100000
	   (footer.php) so tap-to-call stays visible and reachable while the
	   menu is open; bottom padding keeps the last links clear of it too. */
	.js #access.menu-open {
		position: fixed;
		inset: 0;
		/* style.css:1515 sets margin: 10px auto on #access, unscoped by any
		   media query -- a non-auto vertical margin still applies to a
		   fixed, inset:0 box, leaving a 10px gap top and bottom instead of
		   true full-bleed. Zero it here. */
		margin: 0;
		z-index: 99999;
		background: #87c7b5;
		overflow-y: auto;
		/* #header-new (height: 100px, above) plus #wrapper's 12px margin-top
		   (below) sit in normal flow at the top of the page, so the toggle
		   button -- elevated to z-index: 100001 to stay clickable above this
		   overlay -- floats over whatever the overlay paints underneath it.
		   Without this, it straddles the boundary between the first two
		   rows: at 320px wide it covers the bottom 4px of "Aktuellt" and the
		   top 40px of "Mottagningar" (confirmed via getBoundingClientRect on
		   both, live). Push the menu content below the header strip
		   entirely, so the header (wordmark + toggle) reads as its own row
		   and every menu row starts clear of it. */
		padding-top: 112px;
		padding-bottom: calc(56px + env(safe-area-inset-bottom));
	}

	/* Undo the <=980px flow-root: it is only needed while the menu items
	   float, and they stop floating here (li rule below). Left as a BFC,
	   the closed .js #access (its ul is display: none, so the box is
	   empty) would stop its own 10px top and bottom margins collapsing
	   through it, pushing #main down by 10px (measured at 390px wide:
	   #main top 122px with block, 132px with flow-root). */
	#access {
		display: block;
	}

	#access .menu-header,
	div.menu {
		margin-left: 0;
		font-size: 16px;
	}

	#access .menu-header li,
	div.menu li {
		float: none;
		display: block;
		position: relative;
	}

	#access a {
		min-height: 44px;
		line-height: 44px;
		padding: 0 15px;
	}

	/* The overlay's own outline:auto never shows: rows are full-bleed
	   (link width = 100% of #access, no gap between stacked rows), so the
	   ring has nowhere to bleed into that isn't inside the overflow:auto
	   overlay clipping it away (confirmed by pixel-inspecting screenshots
	   -- computed style reported the outline; nothing rendered). An inset
	   ring stays entirely within the link's own box, so it can't be
	   clipped by the ancestor either way. #2a2a2a reads clearly against
	   both the ordinary-row background (#87c7b5) and the current-page
	   background (#2F856B, style.css:1649). */
	.js #access.menu-open a:focus-visible {
		outline: 2px solid #2a2a2a;
		outline-offset: -2px;
	}

	#access ul ul {
		position: static;
		float: none;
		width: auto;
		box-shadow: none;
		-moz-box-shadow: none;
		-webkit-box-shadow: none;
	}

	/* Children indented under their parent -- the only hierarchy cue
	   needed once the whole tree is visible at once. */
	#access ul ul a,
	#access ul ul ul a {
		width: auto;
		line-height: 44px;
		padding: 0 15px 0 30px;
	}

	.no-js .menu-toggle {
		display: none;
	}

	.no-js #access ul ul {
		display: block;
	}

	/* Lock the background while the overlay is open. */
	html.menu-open body {
		overflow: hidden;
	}
}

/* Call bar: hidden on desktop, fixed to the viewport bottom on phones. */
.mobile-callbar {
	display: none;
}

@media (max-width: 800px) {
	.mobile-callbar {
		display: flex;
		position: fixed;
		bottom: 0;
		left: 0;
		right: 0;
		min-height: 56px;
		padding-bottom: env(safe-area-inset-bottom);
		background: #2F856B;
		z-index: 100000;
	}

	/* Two classes, not one: style.css:1258 has `a:link { color: #2f856b; }`
	   (0,0,1,1), which outranks a single class selector (0,0,1,0) on the
	   element tier and would otherwise print green text on the green bar
	   background. `.mobile-callbar .callbar-item` (0,0,2,0) outranks it
	   without `!important`. */
	.mobile-callbar .callbar-item {
		flex: 1;
		display: flex;
		align-items: center;
		justify-content: center;
		min-height: 56px;
		color: #fff;
		font-size: 16px;
		font-weight: bold;
		text-decoration: none;
	}

	.callbar-1177 {
		flex: 0 0 30%;
		background: #20404B;
	}

	/* Keep the bar off the footer address line at page bottom. Two element
	   selectors, not one: WP core's global-styles-inline-css block prints
	   after mobile.css and sets a bare `body{padding-bottom:0}` (0,0,0,1)
	   at equal specificity, which would otherwise win on DOM order alone.
	   `html body` (0,0,0,2) outranks it without `!important`. */
	html body {
		padding-bottom: calc(56px + env(safe-area-inset-bottom));
	}
}
