/* ===== The pinned top section (toolbar + tabs) =====
   The tabs are how a pilot moves between OFP, FDT and HESLO mid-flight, so they stay on
   screen: the page scrolls underneath them and they do not move.

   IT IS PINNED TWO DIFFERENT WAYS, and which one is right depends on how the app was opened.

   In a browser tab, `position:sticky`, which is what has always been here. Sticky stays
   inside the page, so the browser is free to slide its own address bar over the top of the
   page and the bar goes with it.

   In the app installed on the home screen, `position:fixed`, because sticky is NOT HONOURED
   there: the whole page scrolled and took the tab bar with it, leaving a pilot part way down
   a fuel log to scroll back to the top of it to change tab. Fixed is honoured — but it pins
   to the top of the page rather than to the top of what can be seen, so in a browser tab it
   would put the toolbar row up behind the address bar. There is no address bar in the
   installed app, which is exactly why it is safe to use there and only there. js/theme-boot.js
   decides which of the two this is, before the first frame is drawn.

   Fixed positioning is out of the flow, so the room the bar used to take has to be given back
   deliberately: that is the body padding. THE HEIGHT IS NOT A CONSTANT — the tabs wrap onto a
   second line on a phone and will wrap on a wider screen as soon as another tab is added, and
   the bar carries the depth of the status bar above it — so it is a variable measured by
   syncTopbarHeight() in js/app.js. The value here is only what stands for the one frame
   before that has run.

   The safe-area padding is for the same installed app: it is drawn under a translucent status
   bar (viewport-fit=cover, in index.html), and a bar that never scrolls away is a bar whose
   top edge would otherwise sit under the clock for good. */
.topbar{position:sticky;top:0;z-index:30;box-shadow:var(--shadow)}
/* ===== THE TITLE ROW SCROLLS AWAY IN A BROWSER WINDOW =====
   Same outcome as the slide in the installed app below, reached the other way round. The bar
   sticks at MINUS the height of its own title row, so scrolling down carries the title, the
   save state and the menu off the top and comes to rest with the tabs — the row a pilot
   changes mid-flight — against the top of the window. Scrolling back to the top brings the
   row down again.

   No JavaScript moves anything: sticky does it, so it tracks the scroll exactly and cannot
   fall out of step. All that is measured is the height of the title row, by
   measureTopbarSlide() in js/app.js, because it wraps onto two rows on a narrow window.

   The installed app CANNOT do this — sticky is not honoured there at all, which is what the
   note above is about — so it slides the fixed bar with a transform instead. Two mechanisms
   for one behaviour, because the two contexts pin the bar in two different ways. */
html:not(.installed) .topbar{top:calc(0px - var(--toolbar-h,0px))}
/* THE BAR NEEDS A COLOUR OF ITS OWN, which it otherwise would not: everything you can see in
   here is drawn by .toolbar and .tabs below. That is fine while .topbar is exactly as tall as
   the two of them, but the padding above adds a band belonging to neither, and an unpainted
   band is a transparent one — it showed as a gap across the top of the installed app with the
   fuel table scrolling up through it. The strip below covers that band once the bar starts
   moving; this is what stands under it, and what covers the band on a device with no inset at
   all. It is the colour the toolbar's gradient starts at, so the two read as one bar. */
html.installed .topbar{position:fixed;left:0;right:0;
  padding-top:env(safe-area-inset-top,0px);background:var(--toolbar1)}
html.installed body{padding-top:var(--topbar-h,110px)}
/* ===== THE STATUS-BAR STRIP, AND WHAT THE TITLE ROW SLIDES BEHIND =====
   updateTopbarSlide() in js/app.js moves the whole bar up by however far the page has been
   scrolled, stopping once the title row has gone — so the row travels with the page and the
   tabs come to rest under the clock. See the note there for why it moves rather than shrinks.

   THE ROW HAS TO DISAPPEAR BEHIND SOMETHING, or its bottom edge and rule would still be drawn
   across the status bar at the end of the slide. So the band that clears the clock is painted
   here instead of by the bar: a strip of its own, over the top of everything the bar does. It
   hangs off <body> rather than off .topbar because the bar carries a transform, and a fixed
   element inside a transformed one travels with it — which is exactly what this must not do.

   It changes colour once, at the end of the slide, from the toolbar it was sitting above to
   the tabs it is sitting above now, so it reads as part of the bar in both positions. The two
   are a few shades apart and it is given a moment to cross between them, which is what stops
   the one discrete step in this whole movement from being visible. */
html.installed body::before{content:"";position:fixed;top:0;left:0;right:0;z-index:31;
  height:env(safe-area-inset-top,0px);background:var(--toolbar1);pointer-events:none;
  transition:background-color .18s linear}
html.installed.topbar-slim body::before{background:var(--tabbg)}
.toolbar{display:flex;align-items:center;gap:12px;flex-wrap:wrap;
  padding:10px 16px;background:linear-gradient(180deg,var(--toolbar1),var(--toolbar2));
  border-bottom:1px solid var(--line)}
#menuBtn{font-size:22px;line-height:1;padding:8px 15px;min-width:46px;min-height:44px}
.toolbar h1{font-size:16px;letter-spacing:.5px;display:flex;align-items:center;gap:8px}
.toolbar .spacer{flex:1}
.btn{background:var(--panel2);color:var(--ink);border:1px solid var(--line);
  padding:6px 12px;border-radius:7px;cursor:pointer;font-size:13px}
.btn:hover{background:var(--btnhover)}
a.btn{text-decoration:none;display:inline-flex;align-items:center;justify-content:center}
#saveState{font-size:12px;color:var(--muted);min-width:120px;text-align:right}
/* Narrow screens: let the toolbar breathe onto multiple rows instead of overflowing.
   The title takes its own row; the save-state chip and action buttons wrap below,
   left-aligned, so nothing gets pushed off-screen (no sideways scrolling). */
@media (max-width:640px){
  .toolbar{gap:8px;padding:8px 12px;flex-wrap:nowrap}
  .toolbar h1{min-width:0;overflow:hidden;text-overflow:ellipsis;white-space:nowrap}
  #saveState{min-width:0;text-align:right}
  .toolbar .btn{padding:6px 10px}
}
/* ===== THE TAB BAR =====
   Eleven tabs in four groups — OPS the flight being planned, WORK the record being kept of
   it, DOCS the paperwork, EMG the flight manual's actions — and the bar is ONE ROW HIGH at
   every width. Only the way you reach the eleven changes. See the note above the markup in
   index.html for the arrangement; this is how it is drawn.

   FROM 740px UP it is all on one line: the three group buttons, a rule, the tabs of whichever
   group you are in, and then VEMD and CWP hard against the right-hand end. Nothing is hidden
   and nothing drops down — every tab of the job you are doing is one press away, changing job
   is one press on its name, and the flight manual's two are one press from anywhere. An iPad
   held upright is inside this, and so is every laptop.

   BELOW 740px there is not room for all of it, and a second row would cost a row of the fuel
   log for good. So the bar is four group buttons — EMG is one of them again — and the open
   group's tabs drop down OVER the page. That is what a phone already did, unchanged.

   THE BUTTONS ARE THE SAME SIZE EITHER WAY, and the same size they have always been: nothing
   here is shrunk to make it fit. What gives at 740 is which half of the bar is on screen, not
   how big anything is.

   Both rows are in the markup at all times and the CSS decides what is drawn, so none of this
   depends on JavaScript having run. Two attributes on .tabs drive it: data-cur, the group
   holding the view on screen, and data-open, the group whose tabs are down on a phone. */
.tabs{position:relative;display:flex;flex-direction:column;
  padding:8px 12px 0;background:var(--tabbg);border-bottom:1px solid var(--line)}
.tabrow{display:flex;gap:2px;flex-wrap:wrap}
.tab,.tabgroup{padding:9px 18px;border:1px solid var(--line);border-bottom:none;
  background:var(--panel);color:var(--muted);border-radius:8px 8px 0 0;cursor:pointer;font-weight:600}
/* WHERE YOU ARE IS ORANGE, and orange is used for nothing else on this bar. It replaces the
   blue outline that used to mark it: blue is the app's accent and is already the ring round
   every input box on the page, so the one thing that had to stand out was drawn in the same
   colour as the most ordinary thing on the screen. */
.tab.active,.tabgroup.current{background:var(--panel2);color:var(--tabon);border-color:var(--tabon)}
:root{--tabon:#fb923c}
html[data-theme="light"]{--tabon:#c2410c}

/* ---------- the group buttons ---------- */
.tabgroups{display:flex;gap:2px;flex-wrap:wrap}
/* Only ever drawn below 740px, where the two red tabs are not on the bar — see .tabgap. */
.tabgap{display:none}
/* The header of the group whose tabs are down. Only ever set below 740px, where there is a
   drop-down to be open. It is not the same thing as .current, which is the group holding the
   view on screen — press EMG while reading the fuel log and the two are different for as long
   as the drop-down is open. Squaring off the bottom corners joins the header to the strip of
   tabs hanging under it. */
.tabgroup.open{background:var(--panel2);color:var(--ink);border-radius:8px 8px 0 0}
.tabgroup.current.open{color:var(--tabon)}

/* ---------- 740px and up: everything on one line ---------- */
/* WHERE 740 COMES FROM. Measured on the widest case — WORK's four tabs, plus the three group
   buttons and the rule, plus VEMD and CWP — which needs about 690px with the gap squeezed to
   nothing. 740 is that with room for a font a little wider than this machine's. An iPad held
   upright (768) is inside it and so is an iPad mini (744); a phone on its side is not, and
   gets the drop-down below.

   If a font ever did overflow it, .tabrow still wraps: the bar would grow a row rather than
   cut a tab off at the edge. Losing 38px of fuel log is recoverable, a CWP tab you cannot see
   is not. */
@media (min-width:740px){
  .tabs{flex-direction:row;align-items:flex-end;padding:8px 16px 0}
  /* A rule, not a gap. The two halves answer different questions — which job, then which tab
     within it — and side by side without one they read as seven tabs of equal standing. */
  .tabgroups{flex-wrap:nowrap;padding-right:10px;margin-right:10px;
    border-right:1px solid var(--line)}
  /* Narrower than a tab horizontally, never shorter. Three group buttons at a tab's full
     18px sides plus WORK's four tabs plus the two red ones is more than an iPad upright has;
     the height is what makes a button reliable to hit, and that is untouched. */
  .tabgroup{padding:9px 12px}
  /* ONLY THE CURRENT GROUP'S TABS ARE DRAWN. The rest stay in the DOM — the views are
     switched by .view.active, not by this. */
  .tabrow{flex:1;min-width:0}
  .tabrow .tab{display:none}
  .tabs[data-cur="plan"] .tab[data-group="plan"],
  .tabs[data-cur="work"] .tab[data-group="work"],
  .tabs[data-cur="docs"] .tab[data-group="docs"]{display:block}
  /* ===== VEMD AND CWP ARE NOT IN THE GROUPING =====
     They are the flight manual's actions, not a stage of planning a flight, and a pilot
     reaching for them is not choosing between them and FUEL. So they are ALWAYS ON THE BAR
     here, whichever group is open, held against the right-hand end by .tabgap so they are in
     the same place every time — reaching one must never cost a press spent finding it first.
     Which is also why there is no EMG button on this side of 740: it would open a group whose
     tabs are already in front of you. */
  .tabgroup[data-group="emg"]{display:none}
  .tabgap{display:block;flex:1}
  .tabrow .tab.tab-em{display:block}
}

/* ---------- below 740px: the tabs drop down over the page ---------- */
/* 739.98, NOT 739. A window is not always a whole number of pixels wide — a scaled display or
   a browser zoom hands the stylesheet something like 739.5 — and "max-width:739px" with
   "min-width:740px" above leaves that half pixel matching NEITHER. Caught at exactly that
   width: no rule hid anything, and all eleven tabs came back on two rows. */
@media (max-width:739.98px){
  /* THE TABS COME DOWN OVER THE PAGE, NOT ABOVE IT. Pushing the page down would make the bar
     two rows high whenever a group was open, which is the height this whole arrangement
     exists to avoid, and would shift whatever the pilot was reading down the screen every
     time they went looking for a tab. Absolute, so the bar's own height never changes. */
  .tabrow{position:absolute;top:100%;left:0;right:0;z-index:5;
    padding:8px 12px 0;background:var(--tabbg);
    border-bottom:1px solid var(--line);box-shadow:var(--shadow)}
  /* Shut unless its header has been pressed. */
  .tabs:not([data-open]) .tabrow{display:none}
  .tabrow .tab{display:none}
  .tabs[data-open="plan"] .tab[data-group="plan"],
  .tabs[data-open="work"] .tab[data-group="work"],
  .tabs[data-open="docs"] .tab[data-group="docs"],
  .tabs[data-open="emg"]  .tab[data-group="emg"]{display:block}
}
.view{display:none;padding:18px}
.view.active{display:block}
.panel{background:var(--panel);border:1px solid var(--line);border-radius:10px;
  padding:14px;margin-bottom:16px;box-shadow:var(--shadow)}
.panel h2{font-size:13px;text-transform:uppercase;letter-spacing:1px;color:var(--muted);
  margin-bottom:12px;border-bottom:1px solid var(--line);padding-bottom:8px}
/* ===== Section info popovers =====
   Each section's description lives behind an ⓘ button in its header instead of
   sitting permanently under it. .sec-head is the positioning context: the popover
   is absolutely positioned just under the header's rule, so opening one never
   shifts the layout of the section below. */
.sec-head{position:relative}
.info-btn{position:relative;display:inline-flex;align-items:center;justify-content:center;
  width:17px;height:17px;padding:0;margin-left:8px;vertical-align:middle;flex:none;
  border:1px solid var(--muted);border-radius:50%;background:transparent;color:var(--muted);
  font-family:inherit;font-size:11px;font-weight:700;font-style:italic;line-height:1;
  text-transform:none;letter-spacing:0;cursor:pointer;
  transition:border-color .12s,color .12s,background .12s}
/* Invisible padding so a gloved finger on a tablet gets a ~33px target
   without the button itself taking up more room in the header. */
.info-btn::after{content:"";position:absolute;inset:-8px}
.info-btn:hover{border-color:var(--accent);color:var(--accent)}
.info-btn.open{background:var(--accent);border-color:var(--accent);color:#fff}
/* A section-level action sharing the header rule with the title and the ⓘ. Only the
   headers that have one become flex rows — every other h2 in the file is left alone.
   The h2 is uppercase with letter-spacing, which a control should not inherit. */
.sec-head h2.with-action{display:flex;align-items:center}
.head-action{position:relative;margin-left:auto;flex:none;padding:5px 10px;
  font-family:inherit;font-size:11px;font-weight:400;text-transform:none;letter-spacing:0;
  color:var(--muted);background:transparent;border:1px solid var(--line);border-radius:5px;
  cursor:pointer;transition:border-color .12s,color .12s}
.head-action:hover{border-color:var(--accent);color:var(--accent)}
/* Invisible padding, as on .info-btn: a gloved finger gets a ~35px target without the
   control taking more room on the header rule. */
.head-action::after{content:"";position:absolute;inset:-4px}
.info-pop{display:none;position:absolute;top:100%;left:0;z-index:50;
  width:min(560px,100%);margin:6px 0 0;padding:11px 13px;
  background:var(--panel2);border:1px solid var(--line);border-left:3px solid var(--accent);
  border-radius:8px;box-shadow:var(--shadow);
  text-transform:none;letter-spacing:0;font-weight:400;line-height:1.55}
.info-pop.open{display:block}