.main-header {
  width: auto;
  font-size: 0.9rem;
  font-weight: 600;
  padding: 4px;
  margin: 2px;
}

/* Modal titles are h2/h3 in the markup so the heading outline stays flat below
   the visually-hidden h1, but Bootstrap's .modal-title sets no font-size, so
   pin the size the old h5 gave them. Accordion headers are already 1rem via
   .accordion-button, so those need no extra rule. */
h2.modal-title,
h3.modal-title {
  font-size: 1.25rem;
}

.subheader {
  text-align: center;
  font-weight: 600;
  margin: 0px !important;
}

[data-bs-theme="dark"] body {
  background-color: color-mix(in srgb, var(--bs-body-bg) 80%, black);
  color: var(--bs-info-text-emphasis);
}

/* Button surface knobs, see the .btn block further down. Kept next to the theme
   definitions so both tones are tuned in one place. */
[data-bs-theme="dark"] {
  --pfg-btn-bg: #272d34;
  --pfg-btn-shadow: 0 1px 2px rgba(0, 0, 0, 0.45);
  --pfg-btn-shadow-active: inset 0 1px 2px rgba(0, 0, 0, 0.5);
}

/* Soften the pure-white light theme evenly across the whole UI (tune the 94% knob).
   Overriding --bs-body-bg cascades to cards, form controls, etc. that inherit it.
   --bs-tertiary-bg is set a step darker so table headers (.lined th) and the
   input-group "%" addons (.input-group-text) read as slightly muted, not brighter. */
[data-bs-theme="light"] {
  --bs-body-bg: color-mix(in srgb, #fff 96%, black);
  --bs-tertiary-bg: color-mix(in srgb, #fff 82%, black);
  --bs-border-color: color-mix(in srgb, #fff 70%, black);
  --bs-body-color: color-mix(in srgb, #000 85%, white);
  --pfg-btn-bg: #e3e8ef;
  --pfg-btn-shadow: 0 1px 2px rgba(0, 0, 0, 0.18);
  --pfg-btn-shadow-active: inset 0 1px 2px rgba(0, 0, 0, 0.18);
}

/* Darken the page surround around the calculator (tune the 88% knob). The panels
   are transparent .border.rounded boxes, so give them an explicit --bs-body-bg to
   keep them at #f0f0f0 — otherwise they'd show the darker body through. Elements
   carrying a .bg-* utility (!important) keep their own colour. */
[data-bs-theme="light"] body {
  background-color: color-mix(in srgb, #fff 90%, black);
}
[data-bs-theme="light"] .border.rounded {
  background-color: var(--bs-body-bg);
}

/* Mirror the dark theme, where editable inputs sit at the base --bs-body-bg and
   thus read lighter than the darkened surround. Here the surround/panels are
   toned down, so lift editable fields one step above the panels instead.
   readonly/disabled fields keep the panel tone. `ui-state-disabled´ is excluded
   for the same reason: a computed readout rendered as a <div> cannot carry the
   readonly or disabled attribute, so the marker class is its only signal.
   The :not()s also raise specificity above the .border.rounded rule so a
   .form-control.border still lifts. */
[data-bs-theme="light"] .form-control:not([readonly]):not(:disabled):not(.ui-state-disabled),
[data-bs-theme="light"] .form-select:not([readonly]):not(:disabled):not(.ui-state-disabled) {
  background-color: color-mix(in srgb, #fff 100%, black);
}

/* Same interactive-light tone for unchecked radios/checkboxes, so they don't blend
   into the panel. Overriding --bs-form-check-bg touches only the unchecked fill;
   the checked state keeps its primary colour. */
[data-bs-theme="light"] .form-check-input {
  --bs-form-check-bg: color-mix(in srgb, #fff 100%, black);
}

/* Slightly darken the calculator title header (next to the reset button).
   !important beats the .bg-body-secondary utility that colours it. */
[data-bs-theme="light"] .main-header {
  background-color: color-mix(in srgb, var(--bs-secondary-bg) 92%, black) !important;
}

/* Dark theme: sink editable form controls below the readonly/disabled tone so they are visually
   distinct. Editable inputs appear darker (more recessed), while readonly/disabled fields
   keep the panel tone (--bs-secondary-bg) and appear lighter/raised. This makes readonly
   inputs in modals visually distinguishable from editable ones. !important overrides
   Bootstrap's default transparent background. */
[data-bs-theme="dark"] .form-control:not([readonly]):not(:disabled):not(.ui-state-disabled),
[data-bs-theme="dark"] .form-select:not([readonly]):not(:disabled):not(.ui-state-disabled) {
  background-color: rgb(20, 23, 27) !important;
}

/* Modals: Bootstrap paints .modal-content with --bs-modal-color (#dee2e6 in dark
   mode), which reads as white against the calculators' cyan default text. Inherit
   from the page instead — the same fix the accordions carry in flight_bs.css and
   production_bs.css. Set on .modal because that is where Bootstrap declares the
   variable, so this also feeds the `color´ on .modal-content.

   A .table nested in a modal needs its own line: Bootstrap re-colours every cell
   with --bs-table-color (var(--bs-emphasis-color) — plain white in dark mode), so
   the inherited modal colour would stop at the table element. The striped/active/
   hover state variables default to the same emphasis colour and are listed too,
   otherwise the changelog's .table-striped rows alternate cyan and white. */
.modal {
  --bs-modal-color: inherit;
}

.modal .table {
  --bs-table-color: inherit;
  --bs-table-striped-color: inherit;
  --bs-table-active-color: inherit;
  --bs-table-hover-color: inherit;
}

[data-bs-theme="dark"] .nav-tabs .nav-link.active {
  color: var(--bs-primary);
}

/* `:not(.btn)´ keeps these away from Bootstrap buttons, which carry their own
   --bs-btn-color per variant. Without it the dark rule below, at (0,1,1), beats
   `.btn´ at (0,1,0) and paints the label of a solid .btn-primary cyan. */
.subheader,
button:not(.btn) {
  color: #0a58ca;
}

[data-bs-theme="dark"] .form-control,
[data-bs-theme="dark"] .form-select,
[data-bs-theme="dark"] .subheader,
[data-bs-theme="dark"] button:not(.btn) {
  color: var(--bs-info-text-emphasis);
}

/* Buttons read as raised keys. Bootstrap's outline variants leave --bs-btn-bg at
   the base `transparent´, so they render exactly the panel colour while editable
   inputs get a lifted fill — the button ends up looking like a hole in the panel.
   Give the outline variants their own surface; the variant's accent stays in the
   text and the border.

   Do not fold this into a bare `.btn´ selector: that has the same (0,1,0)
   specificity as Bootstrap's .btn-primary and, loading later, would strip the
   fill off the solid variants too. */
.btn-outline-secondary,
.btn-outline-primary,
.btn-outline-danger {
  --bs-btn-bg: var(--pfg-btn-bg);
}

/* Relief and press feedback are safe on every .btn — box-shadow and transform do
   not collide with the --bs-btn-* variables, and the class also covers the
   <div class="btn"> controls in the flight calculator. Bootstrap's own
   .btn:focus-visible ring is (0,2,0) and still wins. */
.btn {
  box-shadow: var(--pfg-btn-shadow);
}

.btn:active,
.btn.active {
  transform: translateY(1px);
  box-shadow: var(--pfg-btn-shadow-active);
}

/* A key that cannot be pressed must not look raised. */
.btn:disabled,
.btn.disabled,
.btn.ui-state-disabled {
  box-shadow: none;
  transform: none;
}

.ui-input-margin {
  margin: 0;
  margin-left: 6px;
}

.hint-label {
  font-size: 0.8em;
}

.ui-checkbox {
  margin-right: 10px;
}

.no-mp {
  margin: 0;
  padding: 0;
}

#reset {
  padding: 4px;
  cursor: pointer;
  float: right;
  margin: 4px;
}

#tabs {
  margin: 4px;
  z-index: 0;
}

#warning {
  padding: 2px;
  margin: 4px;
  text-align: center;
  display: none;
}

#hint {
  padding: 2px;
  margin: 4px;
  margin-top: 20px;
}

#hint-message {
  margin-right: .3em;
  font-weight: lighter;
}

#vtable {
  width: 100%;
}

#vtablesb,
#vtablec {
  vertical-align: top;
}

#vtablesb {
  white-space: nowrap;
}

#vtablec {
  width: 100%;
}

#vtablet {
  text-align: right;
}

#vtablel {
  text-align: right;
}

#topbar {
  width: 100%
}

#topbar td {
  white-space: nowrap;
  vertical-align: center;
}

#startpage {
  font-size: 1.2em;
  padding: 10px;
}

/* Exchange rate inputs (costs / lfcosts / production). They hold MSU weights,
   so fractional values like 1,5 or 1,33 are the norm rather than the exception.
   The text is centered, so the roomy form-control-sm side padding buys nothing
   but clipping — trading it for content width fits the values without making
   the fields any wider. */
#exchange-rates-m,
#exchange-rates-c,
#exchange-rates-d {
  width: 48px;
  padding-left: 2px;
  padding-right: 2px;
  text-align: center;
}

.input-1column {
  width: 20px;
  text-align: center;
}

.input-2columns {
  width: 25px;
  text-align: center;
}

.input-3columns {
  width: 30px;
  text-align: center;
}

.input-4columns {
  width: 40px;
  text-align: center;
}

.input-5columns {
  width: 50px;
  text-align: center;
}

.input-10columns {
  width: 90px;
  text-align: center;
}

.input-20columns {
  width: 180px;
  text-align: center;
}

.input-in-table {
  margin: 0px;
}

.centered {
  text-align: center
}

.left-aligned {
  text-align: left
}

.right-aligned {
  text-align: right
}

abbr {
  border-bottom: .1em dotted;
  cursor: help;
}

/* Read-only and disabled inputs should show the default arrow cursor, not a text caret.
   This applies to readonly attributes and :disabled pseudo-class on inputs and textareas. */
input[readonly],
textarea[readonly],
input:disabled,
textarea:disabled {
  cursor: default;
}
/* Keep value inputs compact when wrapped in a Bootstrap input-group with a unit
   addon: Bootstrap forces `.input-group > .form-control { flex: 1 1 auto; width: 1% }`,
   which would otherwise blow these fixed-width numeric fields up to the browser's
   default text-input width. */
.input-group > .form-control.level-input,
.input-group > .form-control.fleet-input,
.input-group > .form-control.rate-input {
  flex: 0 0 auto;
  width: 3.5rem;
}

/* Tooltip skin shared by every calculator: the Bootstrap default is an opaque
   black bubble that ignores the theme, so repaint it off the theme variables.
   Kept here rather than restated in each `*_bs.css´ — the eight copies this
   replaces were byte-identical.

   The fill is set through --bs-tooltip-bg rather than on .tooltip-inner: that is
   the variable Bootstrap's own arrow rules read, so the arrow follows the bubble
   for free. The copies this replaces instead tried to colour the arrow with
   `.tooltip.bs-tooltip-top .tooltip-arrow::before` and friends, which never
   matched anything — BS5 marks placement with a `bs-tooltip-auto` class plus a
   `data-popper-placement` attribute, so every calculator was drawing the themed
   bubble with a black default arrow. */
.tooltip {
  --bs-tooltip-bg: var(--bs-secondary-bg);
  --bs-tooltip-color: var(--bs-body-color);
  /* A tooltip is informational and must never swallow a click. Without this, the
     bubble of one control can cover its neighbour in a tight button row — the
     flight departure shortcuts, `(now)´ and `(00:00:00)´, sit close enough that
     auto-placement puts one bubble straight over the other button. */
  pointer-events: none;
  --tooltip-arrow-outline: var(--bs-border-color);
  --tooltip-arrow-offset: calc(-1px - 2px);
}

.tooltip-inner {
  border: 1px solid var(--bs-border-color);
  max-width: 250px;
  text-align: left;
}

/* The arrow is a single ::before triangle with no border of its own — giving the
   box a themed outline (above) still left the beak a flat, borderless fill in
   both themes. Bootstrap's popover arrow solves this with a second, inset
   ::after triangle (see .popover-arrow in bootstrap.min.css): ::before is the
   full-size triangle in the outline colour, ::after is the same triangle in the
   fill colour nudged *towards the bubble*, so the part of ::before it no longer
   covers — the tip and a sliver along both diagonal sides — is left showing as
   the outline. Reproduced here per placement since tooltips don't ship that
   second layer.

   The nudge direction is the whole trick: shifting ::after away from the bubble
   instead slides the fill triangle past the outline one and draws two separate
   triangles, one above the other. Bootstrap already offsets ::before by 1px
   into the bubble, so --tooltip-arrow-offset is that 1px plus the 2px of ring
   we want to see, applied on whichever side faces the bubble. 2px rather than
   the popover's 1px because these sides run at 45°, where a 1px shift leaves
   only ~0.7px of ring perpendicular to the edge — thinner than the 1px border
   it has to line up with. Verified against 1x screenshots in both themes.

   Overlapping the bubble is safe even though .tooltip-inner is a later sibling:
   the arrow is absolutely positioned and so paints above it, letting the fill
   hide the bubble's own border where the two meet.

   Selectors repeat the real BS5 selector (`bs-tooltip-auto[data-popper-placement]`)
   and the legacy fixed-placement one (`bs-tooltip-top` and friends) so this
   keeps working if a caller ever pins a placement instead of leaving it auto. */
.tooltip .tooltip-arrow::after {
  position: absolute;
  content: "";
  border-color: transparent;
  border-style: solid;
}

.tooltip.bs-tooltip-auto[data-popper-placement^="top"] .tooltip-arrow::before,
.tooltip.bs-tooltip-top .tooltip-arrow::before {
  border-top-color: var(--tooltip-arrow-outline);
}
.tooltip.bs-tooltip-auto[data-popper-placement^="top"] .tooltip-arrow::after,
.tooltip.bs-tooltip-top .tooltip-arrow::after {
  top: var(--tooltip-arrow-offset);
  border-width: var(--bs-tooltip-arrow-height) calc(var(--bs-tooltip-arrow-width) * .5) 0;
  border-top-color: var(--bs-tooltip-bg);
}

.tooltip.bs-tooltip-auto[data-popper-placement^="right"] .tooltip-arrow::before,
.tooltip.bs-tooltip-end .tooltip-arrow::before {
  border-right-color: var(--tooltip-arrow-outline);
}
.tooltip.bs-tooltip-auto[data-popper-placement^="right"] .tooltip-arrow::after,
.tooltip.bs-tooltip-end .tooltip-arrow::after {
  right: var(--tooltip-arrow-offset);
  border-width: calc(var(--bs-tooltip-arrow-width) * .5) var(--bs-tooltip-arrow-height) calc(var(--bs-tooltip-arrow-width) * .5) 0;
  border-right-color: var(--bs-tooltip-bg);
}

.tooltip.bs-tooltip-auto[data-popper-placement^="bottom"] .tooltip-arrow::before,
.tooltip.bs-tooltip-bottom .tooltip-arrow::before {
  border-bottom-color: var(--tooltip-arrow-outline);
}
.tooltip.bs-tooltip-auto[data-popper-placement^="bottom"] .tooltip-arrow::after,
.tooltip.bs-tooltip-bottom .tooltip-arrow::after {
  bottom: var(--tooltip-arrow-offset);
  border-width: 0 calc(var(--bs-tooltip-arrow-width) * .5) var(--bs-tooltip-arrow-height);
  border-bottom-color: var(--bs-tooltip-bg);
}

.tooltip.bs-tooltip-auto[data-popper-placement^="left"] .tooltip-arrow::before,
.tooltip.bs-tooltip-start .tooltip-arrow::before {
  border-left-color: var(--tooltip-arrow-outline);
}
.tooltip.bs-tooltip-auto[data-popper-placement^="left"] .tooltip-arrow::after,
.tooltip.bs-tooltip-start .tooltip-arrow::after {
  left: var(--tooltip-arrow-offset);
  border-width: calc(var(--bs-tooltip-arrow-width) * .5) 0 calc(var(--bs-tooltip-arrow-width) * .5) var(--bs-tooltip-arrow-height);
  border-left-color: var(--bs-tooltip-bg);
}

/* Flattens <fieldset>/<legend> browser chrome (border, padding, block-level
   legend) so a semantic form-field group can sit inline in a flex row instead
   of rendering as a bordered box. Used where a group heading was a bare
   <label> with no associated control (SonarQube Web:S6853). */
.fieldset-reset {
  border: 0;
  padding: 0;
  margin: 0;
  min-width: 0;
}
/* The float is what puts the legend back in the row. A fieldset lays its
   children out inside an anonymous box that takes the fieldset's own display,
   and the *rendered legend* — the first <legend> child whose float computes to
   `none` — is pulled out of that box and placed above it. So on a `d-flex`
   fieldset a non-floated legend is never a flex item and always sits on its own
   line, however it is styled. Any float disqualifies it from being the rendered
   legend, and it joins the anonymous flex box as an ordinary item, where the
   float itself is then ignored. */
.fieldset-reset > legend {
  float: left;
  width: auto;
  padding: 0;
  margin: 0;
  font-size: inherit;
  line-height: inherit;
}