/* main-content-fullscreen.css - dwt/main-content-fullscreen.dwt's OWN CSS: the template of the FULL-SCREEN pages
   (2026-11-08; the user: "for the full screen pages it could be a bit more simple please ... same DWT as
   dwt/main-content.dwt but less basics, like no menu_banner for dropdowns, just citysearch").

   Its own, not shared with dwt/main-content.dwt (user, 2026-11-08: "If the dwt/main-content.dwt has its css here:
   css2/main-content-layout.css, dwt/main-content-fullscreen.dwt should have its own css, not same as
   dwt/main-content.dwt is using please" - "copy the css2/main-content-layout.css content to
   css2/main-content-fullscreen.css and remove unused lines"): part 0 below IS that file, copied, so a change for one
   template never changes the other - as css2/main-content-layout.css itself once became dwt/main-content.dwt's own
   copy of css2/ad-layout.css.
   Loaded after css2/site-base-andreset.css and css2/theme2.css, the site's own base and theme on every page (the
   search box, the switches and the footer look as everywhere). Its rules win over theirs by specificity, not by order.
   Only this template loads this file.

   Four parts:
     0. the content width and the ad boxes - css2/main-content-layout.css, copied;
     1. the top: ShareThis, then ONE bar - "← Timers and Clocks" with "← Back" right under it and "⛶ Full screen"
        beside the two to the left, the city search, 12h/24h and the theme switch to the right (user, 2026-11-08);
     2. the content filling the rest of the window: the clock's area grows down to the window's bottom edge, its
        content in the middle; the footer comes after it;
     3. ⛶ Full screen: <main id="zone-content"> alone across the whole screen (js2/fullscreen-button.js).
   Each page sizes its own content - the clock's digits - in its own head-extra region. */


/* == 0. The content width and the ad boxes ======================================================================== */

/* Copied on 2026-11-08 from css2/main-content-layout.css (?v=16, md5 fecab7ac), dwt/main-content.dwt's own layout
   file, with the lines these pages do not use removed: that file's header (it describes that template), the menu
   bar's z-index (#menu_banner, .menu_hidden) and the fast links' two rules (these pages have neither), the share
   row's two margins (part 1 sets this template's own: 0 above, 20px below) and, 2026-11-09, the search results
   list's z-index (#menuDropdown - it did nothing here, see below). Four notes say "the template" or "part 1"
   where they spoke of dwt/main-content.dwt. Everything else is as there, so the two files compare line by line -
   except the default --content-max: 3600px here, 1100px there (2026-11-09, see its rule).
   ⚠ The ad boxes are therefore in BOTH files: a change to the ad boxes themselves (their sizes, their classes -
   templates2/ad-block.php) needs both. */
.app > .sharethis-inline-share-buttons {
  /* 2026-10-18: ShareThis now loads LATE (after the page is on screen - see the end of
     the template), so the row keeps its final 32px from the start (5 buttons on one line,
     measured at 1280 and 390px); otherwise the whole page would jump 32px down when the buttons
     arrive. overflow: hidden, so a button that wraps for a moment never shows.
     The 4px padding-top is room for ShareThis's hover lift (.st-btn:hover { top: -4px }) - without
     it the clip would cut the top 4px off the button under the mouse. Height 36px = 4px + the 32px
     row (box-sizing: border-box). The row's margins: part 1 below. */
  padding-top: 4px;
  height: 36px;
  overflow: hidden;
}

/* ShareThis's own script sets an inline z-index (~94034) on its root div.
   Normally z-index does nothing on a position:static element — but .app is
   display:flex, and this div is a DIRECT CHILD of it, making it a flex item.
   Per the flexbox spec, an explicit z-index on a flex item creates a stacking
   context even at position:static (a CSS2 rule exception that only applies
   to flex items). So the 94034 is genuinely active here. On default.html the
   same div is nested several levels deep inside a sidebar — never itself a
   direct flex item — so the exact same inline z-index stays fully inert
   there, which is why the bug never showed up on that page. Fix: go well
   above ShareThis's number - here the bar itself (.fs-bar, part 1: z-index 100000). The search's results list
   sits INSIDE the bar, so it needs no number of its own (theme2.css gives it 500 anyway): the copied
   "#menuDropdown { z-index: 100001 !important; }" did nothing here and was removed (2026-11-09; tested - the list
   still opens over the clock and the ads). */

/* Content column: fluid width, not a fixed number. Floor/ceiling are
   per-page configurable via these custom properties — a page that wants a
   different column overrides them in its own head-extra region, e.g.:
     <style>:root{--content-min:700px;--content-max:800px}</style>
   Defaults below suit the zone-detail pages.

   Supported per-page range: --content-min down to 800px, --content-max up
   to ~1200px — both safe to override without touching this shared file or
   the ad system below. E.g. raise --content-max for a wide feature (the
   Call Planner's card tops out at 1060px), or set --content-min equal to
   --content-max for a fixed non-fluid column (an article page wanting a
   steady 800px width).
   ⚠ --content-min feeds TWO separate breakpoints below, not one:
   .content-grid's own activation point (837px = --content-min + the two
   8px edge insets + 4px to spare, + 17px for a scrollbar) and the rails'
   visibility point (1193px =
   --content-min + 376px, the rails' own footprint, + 17px for a
   scrollbar - see that block). A page overriding
   --content-min away from 800px would need its own copy of BOTH
   breakpoints to stay fully correct. --content-max never affects
   either one. */
/* THIS template's default is 3600px, not 1100px (user, 2026-11-09: "it gives super good experience on wide screen
   users" - "Yes please to start with the 3600px default"): every page on it is a big clock or timer that should fill
   the window, so its content may grow as wide as a big screen allows - the window decides the real width (1529px on
   a 1920px screen, 889px at 1280 beside the side ads, a phone's full width), and on a 1920px screen the digital
   clock's time is 260px tall instead of 187px. Tested at 14 widths with 3600px on that page (2026-11-08). A page that
   wants a narrower column says so in its own head-extra (the template's note there). The two notes above about
   ~1200px and the zone-detail pages are dwt/main-content.dwt's, copied with the rest. */
:root {
  --content-min: 800px;
  --content-max: 3600px;
}

/* A hard minimum never relaxes on its own — true of the grid's minmax()
   floor below (see .content-grid further down) just as it was of the
   old clamp()-based floor this rule originally guarded against
   (original bug: permanent horizontal scrollbar below ~800-830px).
   The grid's own validated floor is 816px = --content-min (800) + the
   two 8px edge insets, confirmed empirically by summing computed
   grid-template-columns rather than assumed — handing off to genuinely
   fluid full-width before that floor would cause overflow.
   836px, not 819px (user, 2026-11-07): a media query measures the window
   WITH its scrollbar, the grid only gets the width beside it. With a
   Windows scrollbar (15px Chrome/Edge, 17px Firefox) the grid started at
   820px wide with only 805px for its 816px, and the content stuck out up
   to 3px: a little sideways scroll on every page on this layout. Now the
   fluid tier runs to 836px (820 + 17 - 1), as the rails' 1193px does. */
@media (max-width: 836px) {
  #zone-content {
    width: 100%;
    box-sizing: border-box;
    padding: 0 16px;
    margin: 0;
  }
}

/* No colour of its own (user, 2026-11-07): a box that no ad covers is plain
   empty space, so a visitor with an ad blocker never sees where ads would go.
   ?ad-slots in the address colours the boxes for that one page view (the
   switch sits in the template's head, beside ?theme=, and sets
   data-ad-slots on <html>). It shows where a page has ad boxes when no ad
   covers them, as on Laragon, where Google sends no ads. A real ad covers the
   colour completely.
   Keep the class name: EasyList, the main ad-blocker list, has a rule for
   ".ad-slot" (checked 2026-11-07), so most blockers remove these boxes and
   their space by themselves. With such a blocker on, ?ad-slots shows nothing.
   No border (user, 2026-11-01): the box is border-box, so the old 1px dashed
   border left only 298x248 inside a 300x250 box (158x598 in a 160x600 rail)
   and cut 2px off the right and bottom of a real ad. */
.ad-slot {
  max-width: 100%;
  overflow: hidden;
}
[data-ad-slots] .ad-slot {
  background: var(--surface);
}

/* Ad system: up to three 300x250 ads sit in a row above content by default;
   two 160x600 rails take over beside content once there's room for both.
   The rails are position:sticky inside a CSS Grid (.content-grid, defined
   in the >=837px media query below — content-grid activates there, but
   the rails themselves stay hidden until their own >=1193px visibility
   rule further down) — see those blocks for the full column layout and
   sticky-offset reasoning; not repeated here so the explanations can't
   drift apart again. */
.ad-top-row {
  display: flex;
  justify-content: center;
  gap: 20px;
  margin: 16px auto;
  max-width: var(--content-max);
}
.ad-top-row .ad-slot {
  width: 300px;
  height: 250px;
  /* min-height too (2026-11-02): the units are RESPONSIVE in AdSense, and when
     Google has no ad for a box, its script writes height:0 onto the box to
     collapse it (tested: a wrapper div in between does not stop it — Google
     walks up to the box). An inline height beats any rule here, but min-height
     still holds, so the box keeps its space and nothing on the page moves.
     The ad tags themselves: templates2/ad-block.php. */
  min-height: 250px;
}

/* Extra top-row ads HIDE (display:none) rather than wrap/stack below when
   they don't fit — deliberately not using flex-wrap for this. Stacking two
   250px-tall ads doubles the vertical space they take on a short mobile
   page, which is exactly what the original ad-pair system's "single ad
   only below 650px" rule was built to avoid (Coalition for Better Ads
   30%-of-content density guideline). Numbers: 3 ads need 940px
   (3*300 + 2*20 gaps), 2 need 620px; +32px assumed outer page padding. */
.ad-top-2,
.ad-top-3 {
  display: none;
}
@media (min-width: 652px) {
  .ad-top-2 {
    display: block;
  }
}
@media (min-width: 972px) {
  .ad-top-3 {
    display: block;
  }
}

/* Below 300px wide (user, 2026-11-07) the top row hides altogether - its
   only box there is top 1 (top 2 and 3 need 652px and 972px). The box
   shrinks with the screen (.ad-slot max-width: 100%), but the ad inside
   stays 300px wide (its size is on the tag, templates2/ad-block.php), so
   its right side was cut off: 30px at 270px. Very few screens are this
   narrow; those few get no ad instead of a cut one.
   ⚠ .ad-top-1 itself must be hidden, not only the row: each tag takes its
   display from its OWN box (display: inherit), and the script in
   ad-block.php asks Google for every tag whose display is not none - a tag
   in a hidden row but a shown box would still be asked for, with no room
   to show it. Hiding the row too drops its two 16px margins, which would
   otherwise stay above the content as an empty 32px gap.
   div.ad-top-row wins over .ad-top-row's display: flex by specificity, not
   by order. */
@media (max-width: 299px) {
  div.ad-top-row,
  .ad-top-1 {
    display: none;
  }
}

.ad-side-left,
.ad-side-right {
  display: none;
}

/* >=837px: .content-grid becomes a real CSS Grid, and #zone-content's
   width comes from the grid's own minmax() column instead of a
   separate clamp() rule (deleted — that job is fully absorbed here
   now). The grid needs 816px (--content-min 800 + the two 8px edge
   insets, confirmed empirically); 837px leaves room for a 17px
   scrollbar, which a media query counts but the grid cannot use (820px
   until 2026-11-07 — see the @media(max-width:836px) rule above for the
   handoff below this point).
   Note this is a LOWER threshold than the rails' own visibility
   (1193px, in the separate block below): between 837-1193px, content
   is already grid-sized and fluid, but rails still aren't shown —
   there isn't room for them beside content yet specifically. */
@media (min-width: 837px) {
  .content-grid {
    display: grid;
    /* 7 columns: fixed 8px edge inset | rail | FLEXIBLE gap | clamped
       content | FLEXIBLE gap | rail | fixed 8px edge inset. The
       flexible space belongs BETWEEN rail and content, not between the
       edge and the rail — that's what actually keeps rails pinned near
       the true edge (constant 8px, like the old position:fixed left/
       right) while pushing them away from content as the screen widens.
       (First attempt had this backwards: a flexible outer spacer next
       to a fixed inner margin, which pinned rails near CONTENT instead
       of near the edge on wide screens — caught live at a real 1904px
       window via resize_window.) The gap itself is var(--rail-gap,
       1fr) — a bare 1fr by default, upgraded to a real 20px floor by
       the :has(.ad-side-left) rule further down, once a rail is both
       wide enough to show AND actually present (see that rule's own
       comment for why a bare 1fr alone wasn't enough there). */
    grid-template-columns: 8px auto var(--rail-gap, 1fr) minmax(var(--content-min), var(--content-max)) var(--rail-gap, 1fr) auto 8px;
    grid-template-areas:
      ".  .    .  top   .  .     ."
      ".  left .  main  .  right .";
    /* align-items:start — without this, the grid's default stretch
       would make the rail and #zone-content match each other's height
       instead of each sitting at its own natural size. */
    align-items: start;
  }
  .ad-top-row {
    grid-area: top;
  }
  .ad-side-left {
    grid-area: left;
  }
  .ad-side-right {
    grid-area: right;
  }
  #zone-content {
    grid-area: main;
    /* This tier used to have its own width:clamp(...)+margin:0 auto —
       deleted once the grid column's own minmax() started doing that
       clamping, so this just fills the cell instead of sizing itself
       independently. */
    width: 100%;
    margin: 0;
  }
}

/* Split off from the grid-structure block above (they used to be one
   rule) — this one governs rail VISIBILITY specifically, and needs to
   stay at 1193px even once the grid structure itself moves to a lower
   breakpoint, since rails should only appear once there's actually room
   for them beside content, not as soon as content itself goes fluid.
   Comes after the 652px/972px rules in source order so it correctly
   re-hides ad-top-2/3 here even though both are already "revealed" by
   those individually.
   1193px, not 1176px (user, 2026-11-07): the grid's columns need 1176px
   (8 + 160 + 20 + 800 + 20 + 160 + 8), but a media query measures the
   window WITH its scrollbar, and the grid only gets the width beside it.
   On Windows a scrollbar takes 15px (Chrome, Edge) or 17px (Firefox), so
   at 1176-1182px wide the grid had 1161-1167px and the right rail stuck
   out up to 7px: a little sideways scroll on every page with ads.
   1176 + 17 covers the widest scrollbar. Where a scrollbar takes no
   width (phones, Macs by default) the rails just show 17px later, with
   the three ads above the content until then. */
@media (min-width: 1193px) {
  .ad-top-2,
  .ad-top-3 {
    display: none;
  }

  .ad-side-left,
  .ad-side-right {
    display: block;
    width: 160px;
    height: 600px;
    min-height: 600px; /* keeps the rail's space when Google collapses an
                          empty ad — see ".ad-top-row .ad-slot" above */
    /* position:sticky, not fixed — the actual fix for "the top margin
       stays even when scrolled." A sticky element sticks relative to its
       own normal in-flow position, which (as a grid item right after the
       header/nav in the document) already starts below the header — so
       top:20px only takes effect once scrolling has carried the rail's
       natural position above that line, i.e. after the header has
       already scrolled out of view. Unscrolled: rail sits at its natural
       position, clearing the header for free — no more hardcoded 200px
       needed. Scrolled: catches and holds at 20px from the viewport top
       instead of 200px, freeing the space this redesign was about.
       Bonus: it also releases at .content-grid's own bottom edge
       (roughly content's end) instead of floating past the footer the
       way position:fixed always did. */
    position: sticky;
    top: 20px;
  }

  /* ⚠ Bug found live 2026-07-08: the rail-to-content gap column (a bare
     1fr in the grid above) could render at 0px even with rails visible.
     CSS Grid gives finite-max tracks (content's minmax(800,1100))
     priority over flexible 1fr tracks when handing out leftover space —
     so content claims everything up to its own 1100px cap FIRST, and
     the gap only gets what's left AFTER that. Content doesn't actually
     reach 1100px until ~1436px wide (8+160+gap+1100+gap+160+8 with both
     gaps at 0) — below that, the whole 1176-1436px range (which
     includes very common widths like 1366px) had rails sitting flush
     against content with zero breathing room. Fix: give the gap a real
     20px floor, matching what the 1176px threshold's own math already
     assumed (376 = 2 x (8 + 160 + 20)) but the bare 1fr silently didn't
     enforce. :has(.ad-side-left) keeps this scoped to pages that
     actually have a rail — a no-ads page has nothing to keep distance
     from, so it stays a cost-free bare 1fr there instead of wasting
     40px it doesn't need. Relies on :has() — a newer CSS feature than
     anything else in this file, but supported in all major browsers
     since ~2023, so not a practical compatibility concern by 2026. */
  .content-grid:has(.ad-side-left) {
    --rail-gap: minmax(20px, 1fr);
  }
}


/* == 1. The top =================================================================================================== */

/* 16px above the share buttons + their own 4px (room for ShareThis's hover lift - part 0) = 20px from the top of the
   page to the buttons, and 20px from the buttons to the bar. On dwt/main-content.dwt's pages .app has 24px
   (theme2.css) and the share row 22px above and 26px below it (css2/main-content-layout.css), under the menu bar.
   The share buttons themselves: nothing here - their look is the ShareThis portal's (see the template). */
.app.fs-app { padding-top: 16px; }
.app.fs-app > .sharethis-inline-share-buttons { margin-top: 0; margin-bottom: 20px; }

/* The bar is a grid (user, 2026-11-08):
   - "← Back" right under "← Timers and Clocks", as a pair as tall as the search box, ⛶ beside them (the left column,
     .fs-bar-left, below);
   - on a narrow screen (below 760px, where the line no longer fits: 270 + 262 + 152px + gaps) the two links stay
     together and the search gets its own line under them, with the switches beside it - so nobody using the search
     clicks "← Back" by accident (it used to drop under the search).
   (The share buttons were in this grid for a while that day, their right end on the Search button's - see the
   template for why they went back to a row of their own.)
   Rows 10px apart; 12px between the columns, so between the Search button and the 12h/24h switch (user, 2026-11-08:
   "2px more margin between Search button and 12h/24h button" and between 12h/24h and the theme switch, ".fs-bar-toggles"
   below - "The idea is to have Search button under ShareThis right end": the two 2px move the Search button 4px to the
   left, the 4px it ended past the share buttons' right end - measured 0px apart at 1280 and 1920. A match by measure,
   not by structure: it holds while the bar is its full 965px - windows from about 1015px wide (965 + 32 + a 15px
   scrollbar; 6px off at 1000) - and while the share buttons are as the ShareThis portal has them now; a page with no
   12h/24h switch (the countdown) keeps the switch's room, empty - see .fs-bar-toggles below).
   Each cell in the middle of the bar's line (align-items: center): with a mouse all of them are the search box's
   38px, but on a touch screen the two links take more room (20px between them - "← Back" at the end of this part),
   and the search, the switches and ⛶ stay on one middle line beside them.
   965px wide at most, as the header and the menu bar on the other pages - not the content's width,
   which here grows to 3600px (part 0). position + z-index: above the ShareThis row (its
   script gives it an inline z-index of about 94034 - see part 0) and the ads, so the search's results
   list opens over them, as #menu_banner's 100000 does on the other pages. */
.fs-bar {
  display: grid;
  grid-template-columns: 1fr auto auto;
  grid-template-areas: "left search toggles";
  column-gap: 12px;
  row-gap: 10px;
  align-items: center;
  width: calc(100% - 32px);
  max-width: 965px;
  margin: 0 auto;
  position: relative;
  z-index: 100000;
}
/* The left column (user, 2026-11-08: "Could texts ← Timers and Clocks / ← Back fit on same height please?" - the
   height of the search box, 38px): the two links one above the other (.fs-bar-links), together exactly 38px - two
   17px lines (.fs-link) and 4px between them (.fs-back, at the end of this part), so still 10px from the home link's
   baseline to the capitals of "Back" -, and ⛶ Full screen beside them, in their middle: on the same middle line as
   the search, 12h/24h and the theme switch, where it was before (the home link and ⛶ used to share the 38px line,
   with "← Back" 11.5px below the search box). A page with no "← Back" has its home link alone in the middle of the
   38px. On a screen 320px wide or less ⛶ is not shown at all (.fs-full below); should it still not fit beside the
   links (a wider fallback font), it goes under them, not off the screen. */
.fs-bar-left {
  grid-area: left;
  min-width: 0;
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  gap: 10px;
  min-height: 38px;
}
/* The two links: a column (so "← Back" sits right under the home link by its own margin - in a plain block, the line
   it would sit on keeps the page's 24px line height and no margin brings it closer); each as wide as its words, so
   the space beside "← Back" is not a link. */
.fs-bar-links {
  display: flex;
  flex-direction: column;
  align-items: flex-start;
}
.fs-bar-toggles {
  grid-area: toggles;
  display: flex;
  align-items: center;
  gap: 12px; /* 12h/24h <-> the theme switch: 2px more than 10 (user, 2026-11-08 - see the bar above) */
  min-height: 38px;
}
/* A page with no 12h/24h switch (its "toggle-1224" region left empty - the countdown): from 760px, where the bar is
   one line, the switch's room is kept, empty, so the Search button still ends under the share buttons' right end and
   the theme switch stays where it is on the other full-screen pages (user, 2026-11-09: "B" - shown as pictures: A the
   Search button 115px further right, as it was; B this; C the theme switch right after the Search button). 102.77px =
   the switch's width (its "12h" and "24h", measured at 1280 on the analog and digital clock's page); the 12px gap after
   it is the row's own. Below 760px the search has a line of its own, and there the room stays the search field's.
   Browsers without :has() (before 2022/2023) skip this rule: the Search button 115px further right, as before. */
@media screen and (min-width: 760px) {
  .fs-bar-toggles:not(:has(.fmt-seg))::before {
    content: "";
    flex: 0 0 102.77px;
  }
}
@media screen and (max-width: 759px) {
  .fs-bar {
    grid-template-columns: 1fr auto;
    grid-template-areas:
      "left   left   "
      "search toggles";
  }
}

/* The links ("← Timers and Clocks", "← Back"): the site's UI font in the menu's quiet colour, the accent under the
   mouse; the menu's blue in the light theme, as on the sky picture behind it. 15px text on a 17px line (was 1.3 =
   19.5px), so the two fit the search box's 38px with 4px between them (.fs-bar-left above). */
.fs-link {
  font: 500 15px/17px var(--font-ui);
  color: var(--mid);
  text-decoration: none;
  white-space: nowrap;
}
.fs-link:hover { color: var(--accent2); }
[data-theme="light"] .fs-link { color: #0404bf; }
[data-theme="light"] .fs-link:hover { color: #000099; }

/* "⛶ Full screen": a pill like the theme switch (theme2.css .theme-toggle), with words. It starts hidden in the HTML
   (the hidden attribute) until js2/fullscreen-button.js finds that the browser can do it.
   Its height (user, 2026-11-08): first as tall as the 12h/24h switch ("I would do the 2 please" - of three buttons of
   three heights, 27, 34 and 24px, only this one changes): the same text, 13px at line-height 1.5, and the same 7px
   above and below it - 1px border + 6px padding here, 1px border + 2px + 4px padding there (theme2.css .fmt-seg /
   .fmt-opt) - so 33.5px, exactly the switch's, on the same pixel rows (checked pixel by pixel, both themes). It still
   looked 1-3px taller: in the dark theme the switch's outer ring is faint, and the eye reads it by its brighter
   selected half, 28px. So 1px less - first as a test ("Could the Full Screen button be 1px less tall please for
   test?"), then kept ("This is good"): a 19px line instead of 19.5 - 33px. Was 27px (line-height 1). */
.fs-full {
  background: none;
  border: 1px solid rgba(241,240,249,.18);
  border-radius: 100px;
  color: rgba(241,240,249,.55);
  font: 600 13px/19px var(--font-ui);
  padding: 6px 12px;
  cursor: pointer;
  white-space: nowrap;
  transition: color .15s, border-color .15s;
}
.fs-full:hover { color: rgba(241,240,249,.9); border-color: rgba(241,240,249,.38); }
[data-theme="light"] .fs-full { background: rgba(255,255,255,.80); border-color: rgba(24,24,47,.20); color: rgba(24,24,47,.70); }
[data-theme="light"] .fs-full:hover { background: rgba(255,255,255,.95); border-color: rgba(24,24,47,.40); color: rgba(24,24,47,.95); }
/* Not shown at all on a screen 320px wide or less (user, 2026-11-09: "hide Full screen below 300px - but maybe
   preferably at 320px, since the button drops at 315px viewport on new line"). There it no longer fits beside the
   two links (150 + 10 + 109px = 269px, + the bar's 32px, + on a computer a 15-17px scrollbar - so 316-318px), and
   js2/fullscreen-button.js shows it only after the page is drawn: it dropped to a line of its own and everything
   below moved down 43px (measured at 290px). Hidden there, nothing appears and nothing moves; the browser's own full
   screen remains (F11 on a computer), and an iPhone never shows the button anyway. (0,2,0) beats .fs-full. */
@media screen and (max-width: 320px) {
  .fs-bar .fs-full { display: none; }
}

/* The city search, out of the menu bar. theme2.css sizes and places it for that bar (37px from the menu, the bar's
   50px height, 272px wide, anchored to the bar on phones); here it takes its own grid cell - as wide as it is on a
   wide screen, and on a narrow one the line beside the switches, where its field shrinks (min-width: 0) to fit.
   (1,1,0) wins over theme2.css's (1,0,0) at every width. */
.fs-bar #menu_b_search { grid-area: search; margin: 0; width: auto; height: auto; min-width: 0; position: relative; }
.fs-bar .search { width: 100%; min-width: 0; }
.fs-bar .search-field { flex: 1 1 auto; min-width: 0; }
.fs-bar #menuSearchInput { flex: 1 1 auto; min-width: 0; }

/* The results list: under the field, its right edge on the field's (62px = the Search button and its 2px gap), as on
   the other pages. On a narrow screen it spans the bar instead - anchored to .fs-bar, as the box around the field goes
   position: static - so its 380px never runs off the screen's left edge. */
.fs-bar #menuDropdown { top: calc(100% + 4px); left: auto; right: 62px; width: 380px; }
@media screen and (max-width: 600px) {
  .fs-bar #menu_b_search { position: static; }
  .fs-bar #menuDropdown { left: 0; right: 0; width: auto; }
}

/* Light theme: the search as mild as the pills beside it (user, 2026-11-08: "could the Search City or Country Search
   on light theme be more mild? it is too much there" - three looks shown, "Yes please to make C"). theme2.css gives it
   a solid white field and a solid blue Search button, made for the blue menu bar of the other pages; here, alone on
   the sky picture, it was the loudest thing in the bar. Now the field and the button take the colours of the
   12h/24h and theme pills (theme2.css .fmt-seg / .theme-toggle, light): white at 80%, a thin border, grey text -
   stronger under the mouse and while typing. The border is an inset shadow, so the boxes keep their size exactly.
   The dark theme is unchanged (user: "dark theme is fine, just the light theme please"). (1,2,0) / (0,3,0) win over
   theme2.css's light rules (1,1,0) / (0,2,0). */
[data-theme="light"] .fs-bar #menuSearchInput {
  background: rgba(255,255,255,.80);
  box-shadow: inset 0 0 0 1px rgba(24,24,47,.20);
  color: rgba(24,24,47,.90);
}
[data-theme="light"] .fs-bar #menuSearchInput::placeholder { color: rgba(24,24,47,.55); }
[data-theme="light"] .fs-bar #menuSearchInput:focus {
  background: rgba(255,255,255,.95);
  box-shadow: inset 0 0 0 1px rgba(24,24,47,.40);
}
[data-theme="light"] .fs-bar .search-go {
  background: rgba(255,255,255,.80);
  box-shadow: inset 0 0 0 1px rgba(24,24,47,.20);
  color: rgba(24,24,47,.70);
}
[data-theme="light"] .fs-bar .search-go:hover {
  background: rgba(255,255,255,.95);
  box-shadow: inset 0 0 0 1px rgba(24,24,47,.40);
  color: rgba(24,24,47,.95);
}

/* "← Back": right under "← Timers and Clocks", as a pair (user, 2026-11-08: "← Back could be closer to
   ← Timers and Clocks", then "could there be less vertical margin between" them, then "Could texts ... fit on same
   height please?" - the search box's 38px). 10px from the home link's baseline to the capitals of "Back" with a mouse
   (4px between the two 17px lines; the two together 38px); 20px on a touch screen (a phone, a tablet), where the two
   links sit right on top of each other and a finger needs the room to hit the right one - about the least spacing
   the accessibility guidelines ask for between small tap targets (WCAG 2.5.8). There the two take 48px, 10px more
   than the search box, and the bar's other cells stay in their middle (.fs-bar, align-items). By the pointer, not the
   width: a tablet on the wide layout is touched too. */
.fs-back { margin-top: 4px; }
@media (pointer: coarse) {
  .fs-bar .fs-back { margin-top: 14px; }
}


/* == 2. The content fills the window ============================================================================== */

/* <main id="zone-content"> is at least as tall as the part of the window left under everything above it - the share
   buttons, the bar and the top ad row - and the content sits in the middle of that part. The footer comes after it
   (a page may add space before the footer in its own head-extra: the digital clock's 700px).
   That height: the window's height minus where <main> starts. Where it starts is --fs-top, measured by the template's
   own small script right after the content (dwt/main-content-fullscreen.dwt), before the page is first drawn. The
   window's height is this file's own (user, 2026-11-08: "Could the code ... be stronger and more simple please?"):
   100svh - the screen's height with a phone's address bar showing, which stays the same while the bar slides away
   during scrolling. (Until then the script measured the window's height too: on a phone the bar sliding away made
   the window taller, the clock's area grew and the clock moved down about 30px mid-scroll.) On a computer 100svh is
   simply the window's height, and follows it when the window is made taller or lower - no script needed for that.
   Browsers older than 2022 (svh came in Chrome 108, Safari 15.4, Firefox 101) skip the svh line and keep the 100vh
   one: on a phone of then the height with the bar hidden - steady too, the clock a little below the middle while
   the bar shows.
   The window's rest, not the grid row's height: from 1193px wide the side ads (600px tall) make the content's row
   taller than what is left of a laptop's window, and a clock in the middle of the ROW sat half below the window's
   bottom edge (measured at 1280x800 on the first try: its time at 646-820px, the date at 819-848px). The side ads may
   still reach below the window; the footer then comes after them.
   Without the script (or before it runs) both lines give 0 - no fill: the content sits right under the ads. When
   <main> starts below the window's bottom edge (a very low window), the height comes out below 0 and counts as 0. */
.fs-app #zone-content {
  display: flex;
  flex-direction: column;
  justify-content: center;
  min-height: calc(100vh - var(--fs-top, 100vh));
  min-height: calc(100svh - var(--fs-top, 100svh));
}

/* A page WITHOUT ad boxes (its "ad-block" region's include switched off - the countdown's full screen, 2026-11-09): with
   no ad row, nothing came between the bar and the content, and a content that fills the window touched the bar, right
   under the search box (user: the box "tends to go on top of the city search box on some browser window sizes"; with
   the ads the row keeps them apart). Then 30px between the bar and the content (user, 2026-11-09: "Yes please to add the
   30px gap").
   How the stylesheet knows there are no ads: :has() - "the content grid has no ad row inside it". The top ad row,
   <div class="ad-top-row">, comes into the page only with templates2/ad-block.php; a page that switches the include off
   has none. It does not depend on whether Google fills the boxes: a page with boxes keeps the boxes' room (also when an
   ad blocker hides the ads) and gets no gap. Browsers without :has() (before 2022/2023) skip this rule: no gap, as before.
   A margin, not a padding: --fs-top (the template's script) measures where <main> starts, so the fill above and a page's
   own sizes (the countdown's display) count the 30px by themselves. ⛶ Full screen does not show it: the browser takes
   every margin off the full-screen element. Won by specificity: (1,3,0) beats part 0's #zone-content margin rules. */
.fs-app .content-grid:not(:has(.ad-top-row)) #zone-content {
  margin-top: 30px;
}


/* == 3. ⛶ Full screen ============================================================================================= */

/* <main id="zone-content"> alone on the screen (js2/fullscreen-button.js). The browser makes it as big as the screen
   (its own stylesheet: position fixed, 100% wide and tall); here its background, so the clock is not drawn on the
   browser's black, and 20px all round. The page's own colours: dark #07070e (--bg), light white (the page's colour
   under the sky picture - --bg is a light grey there). The content stays in the middle (part 2). */
.fs-app #zone-content:fullscreen {
  background: var(--bg);
  padding: 20px;
  overflow: auto;
}
[data-theme="light"] .fs-app #zone-content:fullscreen { background: #FFFFFF; }
.fs-app #zone-content::backdrop { background: #07070e; }
[data-theme="light"] .fs-app #zone-content::backdrop { background: #FFFFFF; }