/* ===== DOCS (Documents & Checklists) =====
   A document is drawn from a template (see public/js/doc-templates.js), so this stylesheet
   knows about four kinds of block and nothing about handovers. The look is the operator's
   paper form: sections banded across the width, blocks side by side inside them, and a rule
   round everything — because the pilot filling it in and the crew reading the PDF should be
   looking at the same document.

   THE BLOCKS ARE A FLEX ROW THAT WRAPS, not a table, and that is the whole layout decision.
   A section can hold two blocks or five, of different kinds and different heights, and the
   widths are a hint from the template rather than a fixed grid. On a phone they wrap onto
   their own lines; on the iPad in the aircraft they sit side by side as they do on paper.
   Nothing here uses rowspan, for the reasons written at the top of css/jobs.css. */

.doccard{border:1px solid var(--line);border-radius:10px;background:var(--panel);
  margin-bottom:14px;overflow:hidden}
.doccard+.doccard{margin-top:4px}
/* Adding a document scrolls to the card it just made (docs.js). The toolbar and the tabs are
   pinned over the top of the page, so a card told to go to the top of the screen would go
   under them — the same clearance the day panels keep in css/utilities.css. */
.doccard{scroll-margin-top:calc(var(--topbar-h,110px) + 20px)}

/* ---- the card's header: what this is, and the two things you do with it ---- */
.doccard-head{display:flex;align-items:center;gap:10px;flex-wrap:wrap;
  padding:9px 11px;background:var(--head);border-bottom:1px solid var(--line)}
.doccard-title{font-weight:700;font-size:14px;letter-spacing:.3px}
.doccard-ref{width:170px;max-width:45vw;padding:4px 8px;font-size:12px;
  background:var(--panel2);color:var(--ink);border:1px solid var(--line);border-radius:6px}
.doccard-ref:focus{outline:2px solid var(--accent);outline-offset:-1px}
.doccard-sp{flex:1}
/* Written by refreshDocs, never rebuilt — see the file header in js/docs.js. */
.doccard-prog{font-size:11px;color:var(--muted);font-weight:700;white-space:nowrap}
.doccard-prog.all{color:var(--good)}
.doccard-send{white-space:nowrap}
.doccard-note{padding:8px 11px 0}
.doccard-gone{padding:12px;color:var(--warn);font-size:13px;line-height:1.5}

/* ---- a section ----
   The title is a band across the whole width, exactly as on the form this came from: it is
   what makes CUSTOMER and FUEL read as separate parts of one page rather than as a stack of
   unrelated boxes.

   AND THE JOIN BETWEEN TWO SECTIONS IS ORANGE, which is the one place on this document that
   is not drawn in the form's own greys. Every rule here is --line: round the card, between
   the blocks, under every row of every table. At a glance that made a section boundary look
   exactly like a row boundary, and a crew scanning down a handover for FUEL had to read the
   band to find it. Two pixels of the tab's warning amber is enough to find the edge without
   reading anything, and it is used nowhere else on the document so it cannot be confused with
   a value that means something. Screen only — the PDF writer draws in greys (js/pdf.js), and
   on paper the shaded band is doing this job already.

   EVERY section gets one, the first included. It was left off the top of CUSTOMER on the
   grounds that the card's own edge was already there — but the card's edge is a grey hairline
   and a section join is two pixels of amber, so the top of the document was the one place the
   pattern broke. */
.docsec{border-top:2px solid var(--secrule)}
.docsec-title{background:var(--subhead);color:var(--ink);text-align:center;
  font-size:11px;font-weight:700;text-transform:uppercase;letter-spacing:.8px;
  padding:4px 8px;border-bottom:1px solid var(--line)}
/* The bar under one copy of a repeatable section, holding both of its controls. Looks like
   every other "add" in the app — "+ Add row" under a table, "+ Add day" on a day panel — and
   is left-aligned for the same reason those are: the eye returns to the left edge at the end of
   a section, which is where the next thing to do belongs.

   The two are not styled alike. Adding is the ordinary thing to do and reads as a button;
   removing is the way back from a mistake and is quiet until it is wanted, going red only under
   the cursor. Both are plainly there, which is the fix — a ✕ hidden in the heading band left a
   pilot who had pressed Add by accident with no visible way to undo it. */
.docsec-add{display:flex;align-items:center;gap:8px;flex-wrap:wrap;
  padding:7px 8px;border-top:1px solid var(--line)}
.docsec-addbtn{font-size:12px;padding:5px 12px}
.docsec-rmbtn{font-size:12px;padding:5px 12px;color:var(--muted);background:transparent}
.docsec-rmbtn:hover{color:var(--bad);border-color:var(--bad);background:var(--btnhover)}
.docblocks{display:flex;flex-wrap:wrap;align-items:stretch}
/* Each block claims a share of the row (flex-grow, set from the template's `w`) and every one
   of them is at least readable — below that they wrap onto the next line rather than being
   squeezed into a column too narrow to type a place name into. */
.docblock{flex:1 1 200px;min-width:0;border-left:1px solid var(--line);
  display:flex;flex-direction:column}
.docblock:first-child{border-left:none}
/* EXCEPT A BLOCK OF LABELLED BOXES, WHICH KEEPS ROOM TO WRITE IN. Its label column is a
   measurement rather than a share (--doclab below), so every pixel the section is short comes
   off the box beside it and nothing else: a DETAILS block squeezed to 170px is a 108px name
   against a 62px box, and a registration typed into 62px is scrolled out of sight inside its
   own input. That is not a cosmetic problem — it is a value on a handover that cannot be read
   back.
   So the box gets a floor, and it is the width of the name beside it: a block of labelled boxes
   is never narrower than two label columns. What it takes, it takes from the checklist and the
   remark next to it, which lose a little width and lose nothing by it — one holds four ticked
   lines and the other wraps. docPdfBuild in js/doc-pdf.js divides the printed row the same way,
   so the page and the screen stay the same document. */
.docblock-fields{min-width:calc(var(--doclab) * 2)}
/* A block that took the whole line (docBlockEl sets the basis; this is only the ruling). What
   follows it starts a new line, so its join is the edge ABOVE it and not the one down its
   left-hand side — the same swap the phone rules below make when every block stacks. */
.docblock-full{border-left:none}
.docblock-full+.docblock{border-left:none;border-top:1px solid var(--line)}
/* Centred, like every other heading on the document — the column headings of a table already
   are, and a block title left-aligned above centred columns reads as two different kinds of
   heading. The PDF centres the same three (docPdfHeading in js/doc-pdf.js). */
.docblock-title{background:var(--panel2);color:var(--muted);font-size:10px;font-weight:700;
  text-align:center;text-transform:uppercase;letter-spacing:.5px;padding:3px 7px;
  border-bottom:1px solid var(--line)}

/* ---- labelled boxes ----
   A two-column grid: the label, then the box. The same shape as the CUSTOMER stack on the
   JOBS tab and for the same reason — the label names the box beside it and is not something
   the pilot fills in, so it is styled as a sub-header rather than as data. */
/* THE ROWS DIVIDE THE BLOCK'S HEIGHT BETWEEN THEM, and that is what keeps a section looking
   like one grid. Blocks in a row are all as tall as the tallest — a four-point checklist beside
   a four-box DETAILS — and a grid that packed its rows at their natural height would leave the
   short one ruled off half way down with a gap under it, which reads as a form that stops
   early. `1fr` rows and a grid that fills its block is the same answer css/jobs.css gives for
   the CUSTOMER stack, and it means adding or removing a checklist point re-rules the boxes
   beside it automatically. */
/* THE LABEL COLUMN IS THE SAME WIDTH IN EVERY SECTION, and it is a measurement rather than a
   share of the block. It used to be 34% of whatever the block happened to get, so CAR's DETAILS
   and HELICOPTER's DETAILS — the same kind of stack, one under the other down the page — came
   out with two different label columns because their sections divide the width differently.
   The eye reads down the left-hand edge of a form, and two DETAILS blocks that do not line up
   read as two unrelated forms.
   `minmax(0, ...)` rather than a flat width so that a genuinely narrow block still gives the
   box something to type in instead of overflowing; above that width every one of them agrees. */
/* AND --docbox IS THE BOX BESIDE IT: --doclab is the column of NAMES down the left of a
   section, --docbox is what a pilot TYPES IN, and the two together are what make a table read
   like the labelled boxes above it. Unlike the label column this one cannot be a constant — it
   is whatever is left of a block that took its share of the card — so docSyncBoxWidth in
   js/docs.js measures it and writes it onto the card. The value here is only what stands until
   that has run: roughly a box on a tablet, so a document drawn without it is not wrong, merely
   less exact. See the floor under a sized table column further down. */
.doccard{--doclab:108px;--docbox:180px}
.docfields{display:grid;grid-template-columns:minmax(0,var(--doclab)) 1fr;
  grid-auto-rows:minmax(34px,1fr);align-content:stretch;flex:1}
.docfield-lab{display:flex;align-items:center;justify-content:flex-end;text-align:right;
  background:var(--subhead);color:var(--muted);font-size:10px;text-transform:uppercase;
  letter-spacing:.4px;padding:6px;border-right:1px solid var(--line);
  border-bottom:1px solid var(--line);line-height:1.25}
.docfields input.doc-in{border-bottom:1px solid var(--line)}
.docfields>*:nth-last-child(-n+2){border-bottom:none}

input.doc-in{width:100%;min-width:0;border:none;border-radius:0;background:transparent;
  color:var(--ink);font:inherit;font-size:13px;padding:6px 8px;text-align:left}
input.doc-in:focus{outline:2px solid var(--accent);outline-offset:-2px}
input.doc-in::placeholder,textarea.doc-area::placeholder{color:var(--muted);opacity:.7}

/* ---- free text ----
   A textarea rather than an input, because what goes in these is a sentence about what
   happened today. It may be dragged taller but not wider: wider would push the block out and
   misalign everything beside it. */
.doctext-line{display:flex;flex-direction:column;flex:1;border-bottom:1px solid var(--line)}
.doctext-line:last-child{border-bottom:none}
.doctext-lab{font-size:10px;text-transform:uppercase;letter-spacing:.4px;color:var(--muted);
  padding:5px 8px 0}
textarea.doc-area{flex:1;width:100%;min-height:62px;border:none;border-radius:0;
  background:transparent;color:var(--ink);font:inherit;font-size:13px;padding:6px 8px;
  resize:vertical;white-space:pre-wrap}
textarea.doc-area:focus{outline:2px solid var(--accent);outline-offset:-2px}

/* ---- a checklist ----
   ONE CELL WITH THE POINTS STACKED IN IT, exactly as the JOBS tab does it and as the paper
   form this came from does it. They used to be a ruled row each, which made a four-point
   checklist the tallest thing in its section and pushed the boxes beside it to match — a lot
   of white space to say four short words. There is no rule between points here for the same
   reason there is none on the spreadsheet: a checklist is one list, not four fields.

   The whole row is still the button, because the text is the operator's and not something the
   pilot types — so a large tap target costs nothing and is what a gloved hand on a tablet
   needs. The list sits at the top of its block; the space under it is the block's own. */
.docchecks{display:flex;flex-direction:column;gap:3px;padding:6px 7px}
.docchk{display:flex;align-items:center;gap:7px;width:100%;text-align:left;
  padding:2px 4px;font:inherit;font-size:12.5px;line-height:1.3;cursor:pointer;
  background:transparent;color:var(--ink);border:none;border-radius:5px}
.docchk:hover{background:var(--btnhover)}
.docchk:focus-visible{outline:2px solid var(--accent);outline-offset:-1px}
.docchk-box{flex:none;display:inline-flex;align-items:center;justify-content:center;
  width:21px;height:20px;font-size:12px;font-weight:800;color:var(--good);
  background:var(--panel2);border:1px solid var(--line);border-radius:5px}
.docchk.on .docchk-box{background:var(--goodbg);border-color:var(--good)}
/* Done is struck through and dimmed, so what stays legible is what is still outstanding —
   the same reading the JOBS checklist and the fuel log's transferred rows get. */
.docchk.on .docchk-txt{text-decoration:line-through;color:var(--muted)}

/* ---- a table ----
   THE TABLE TAKES THE WIDTH ITS COLUMNS NEED, and the wrap around it scrolls. That is the
   whole reason a document is readable on a phone.

   The app-wide rule is that a table fills its container exactly (css/tables.css), and cells
   never wrap. Together, on a 375px screen, those two crush a six-column fuel overview into
   about forty pixels a column — and since every cell here holds a text box, what does not fit
   is scrolled out of sight INSIDE that box: no scrollbar, no ellipsis, nothing to swipe. The
   figures are not hidden, they are gone, which is exactly what must not happen to a column of
   remaining litres somebody is about to fly on.

   `min-width:100%` keeps the table filling its block wherever there is room, so a laptop and
   the iPad in the aircraft look as they did. Below that the columns hold their size and
   .doctable-wrap — a .tablewrap, which already scrolls sideways — does what it is for. */
.doctable-wrap{border:none;border-radius:0}
table.doctable{width:auto;min-width:100%;font-size:12.5px}
/* A COLUMN IS AS WIDE AS THIS SAYS AND NOT AS WIDE AS WHAT IS IN IT, because what is in it
   is an input at width:100%, and an input contributes nothing to the width its column asks
   for. So the figure is picked to hold what these columns actually hold — a site name, a
   registration, four digits of litres — rather than left to the browser, which would happily
   give a column of registrations 32px and call it fitted.
   The ✕ column and the row-label column set their own below and are not caught by this. */
table.doctable th,table.doctable td{min-width:112px}
/* Except where the template stated a width for that column (docTableEl in js/docs.js sets it
   on the heading). The floor above is for a column nobody sized; applying it to one that asked
   for a label-column width would quietly hold it 22px wider than the labels it lines up with.
   A SIZED COLUMN HAS ITS OWN FLOOR INSTEAD, and it is --docbox rather than a label column: a
   column of the table holds what the pilot types, so the least it may be is a box to type in.
   LOCATION and S/N on the equipment table ask for one label column each — which lines their
   headings up with REG and HOURS two sections above, and which drew them at the width of the
   WORD "LOCATION" rather than of the place name going into it. */
table.doctable th.doctable-sized,table.doctable td.doctable-sized{min-width:0}
/* The column headings are sub-headers and are coloured like every other one on the document —
   the block titles and the labels beside the boxes. The app-wide rule in css/tables.css puts
   them in --ink, which is the colour of DATA, and next to a muted DETAILS or RMK they read as
   the loudest thing in the section. */
table.doctable th{background:var(--subhead);color:var(--muted);font-size:10px;padding:4px 6px}
table.doctable td{padding:0;border-color:var(--line)}
/* Right-aligned against the boxes they name, exactly as the labels in a DETAILS block are
   (.docfield-lab above): STD sits against its LOCATION box the way REG sits against its own.
   They are the same kind of thing — a name for the row beside it — and on a document where
   every other label does that, a left-aligned column of them reads as data. */
table.doctable td.doctable-rowlab{background:var(--subhead);color:var(--muted);font-size:10px;
  text-transform:uppercase;letter-spacing:.4px;text-align:right;padding:6px;white-space:normal}
/* THE SAME WIDTH AS THE LABEL COLUMN IN A DETAILS BLOCK, and fixed for the same reason. Both
   are "the column of names down the left of a section", one drawn as a grid and one as a
   table, and on a form they must line up.

   Fixed, and not merely a minimum, because of what an added row does. The rows the operator
   named hold text, but a row the PILOT added holds an input in this column — and an input
   asks for a couple of hundred pixels of preferred width, which an auto-laid-out table is
   happy to grant. So the column measured 126px on a handover with three named rows and 219px
   the moment somebody added a fourth: the same section, two different documents, depending on
   whether anybody had typed. Pinning all three cell kinds to one width holds it still. */
table.doctable th.doctable-rowhead,
table.doctable td.doctable-rowlab,
table.doctable td.doctable-rowlab-own{
  width:var(--doclab);min-width:var(--doclab);max-width:var(--doclab)}
table.doctable th.doctable-rowhead{text-align:center}
/* ---- the ✕ column is a MARGIN, not a column ----
   It carries no heading, and on a table where the operator named the first few rows it carries
   nothing at all on those — a ✕ is not offered against STD, because STD is their standing list.
   Ruled like a data column that left three cells empty beside STATUS, which reads as a form
   with something missing from it rather than as a place to press.
   So it has no rules and no fill of its own: the table's own edge closes on STATUS, and the ✕
   sits in the margin outside it, on the rows that have one. */
table.doctable th.doctable-act,table.doctable td.doctable-act{width:34px;min-width:34px;padding:0;
  border:none;background:transparent}
/* A ROW THE PILOT NAMED READS LIKE THE ROWS THE OPERATOR NAMED. The label above it is right
   aligned against the box it names (.doctable-rowlab, and .docfield-lab before that); typed
   into the same column, "Test" was the one thing on the document sitting hard against the left
   while STD, CONTAINER and EXTRA sat against the right. It is the same kind of thing — a name
   for the row beside it — so it is set the same way. */
table.doctable td.doctable-rowlab-own input.doc-cell-in{text-align:right}
/* Left by default, because what a pilot types into a table is words — a location, the state of
   a strap — and prose reads from the left like everything else on the form.
   A table FILLED IN FROM THE PLANNER is the exception: it holds figures copied out of the fuel
   tank register, and those are centred there, in the refuelling log and on the nav log. A
   column of litres left-aligned here beside a centred one on the FUEL tab would read as two
   different tables. The rule is per TABLE rather than per column so that a table cannot come
   out half one way and half the other. */
input.doc-cell-in{padding:6px;text-align:left}
table.doctable.doctable-figures input.doc-cell-in{text-align:center}
/* AND A COLUMN SETS ITS OWN CONTENTS, which overrides both of the rules above. Written onto
   the cell by docTableEl from the column's align (js/doc-templates.js), so an operator laying
   out a form decides it rather than the app inferring it from the width — LOCATION and # on
   the equipment table both state a width and want opposite answers, the place name lining up
   with the boxes in the sections above it and the count sitting under its heading.

   More specific than the fuel table's rule above ON PURPOSE: a column of a table filled in
   from the fuel log still centres by default, and can still be told not to. The column of row
   names is not touched by any of this — it is not one of the operator's columns and keeps the
   alignment set for it further up. */
table.doctable td.doctable-left input.doc-cell-in{text-align:left}
table.doctable td.doctable-centre input.doc-cell-in{text-align:center}
table.doctable td.doctable-right input.doc-cell-in{text-align:right}

/* The FUEL tab's own status colours, on whichever cell holds a remaining figure — see
   docFuelClass in js/docs.js for when. The classes themselves live in css/fuel-log.css and are
   shared rather than restated, so the two screens cannot drift apart. The cell holds an input,
   which carries its own colour, so it has to be told to take the cell's. */
table.doctable td.fuel-green input.doc-in,table.doctable td.fuel-purple input.doc-in,
table.doctable td.fuel-yellow input.doc-in,table.doctable td.fuel-red input.doc-in{
  color:inherit;font-weight:800}
/* The ✕ that takes a row off. Muted until reached for, like the fuel log's own row controls —
   it sits in a column of its own down the side of the table and should not compete with the
   figures beside it. */
/* ---- taking a row off ----
   THIS IS THE CONTROL THAT TAKES A FUEL TANK OFF THE HANDOVER, which is the one thing the
   crew do to this table before sending it — the sites this shift has nothing to do with come
   off, and since docEnsureRows stopped topping the table back up, they stay off.
   Muted until reached for, like the fuel log's own row controls: it sits in a narrow column
   down the side and must not compete with the figures beside it. But it is given a tap
   target's worth of height rather than a glyph's, because it is pressed on a tablet. */
.docrow-x{width:100%;padding:9px 0;font-size:12px;line-height:1.2;cursor:pointer;
  background:transparent;color:var(--muted);border:none}
.docrow-x:hover{color:var(--bad);background:var(--btnhover)}
.docrow-x:focus-visible{outline:2px solid var(--accent);outline-offset:-2px;color:var(--bad)}
/* ---- what you can do to the table, under it ----
   BIG ENOUGH TO FIND AND TO HIT. These were 11px — smaller than any other button on the tab,
   and small enough that "reset from the FUEL tab" read as a footnote and went unnoticed. It
   is not a footnote: it is the only way back from removing a tank. */
.doctable-foot{display:flex;align-items:center;gap:8px;flex-wrap:wrap;margin:8px 6px 6px}
.docrow-add{padding:7px 12px;font-size:12.5px;min-height:34px}

/* ---- adding a document ---- */
.docs-addbar{display:flex;align-items:center;gap:8px;flex-wrap:wrap;margin-top:4px}
.docs-pick{padding:6px 8px;font:inherit;font-size:13px;background:var(--panel2);
  color:var(--ink);border:1px solid var(--line);border-radius:8px;max-width:60vw}
.docs-pick option{background:var(--panel2);color:var(--ink)}
.docs-empty{margin:2px 0 10px}

/* ---- on a phone ----
   ON PAPER THE BLOCKS SIT SIDE BY SIDE; ON A PHONE THEY CANNOT, and pretending otherwise is
   the other half of why a document came out cropped. A four-block HELICOPTER section keeps
   all four on one line right down to its 110px-per-block basis — and 110px is narrower than
   the LOCATION label sitting beside the box it names, so the box gets what is left, which is
   nothing you can read a place name in.

   Below this width the section stops being a row: `display:block` puts each block on the
   whole screen and takes the flex basis the template's `w` sets (docBlockEl in js/docs.js
   writes it as an inline style) out of the argument entirely, so the widths that are right
   for an iPad do not have to be fought here.

   The rule between blocks moves from the left edge to the top, because that is where the
   join now is — the same thing the section band does across the width above them. */
@media (max-width:560px){
  /* And with every block on the whole screen there is no grid for a table column to line up
     with — the box beside REG is now as wide as the phone, and a column matching it would put
     the equipment table three screens across. Back to the width of the heading, which is what
     the column asked for in the first place. docSyncBoxWidth in js/docs.js takes its
     measurement off the card down here so that this can win. */
  .doccard{--docbox:var(--doclab)}
  .docblocks{display:block}
  .docblock{border-left:none;border-top:1px solid var(--line)}
  .docblock:first-child{border-top:none}
  /* The reference box sat at 45vw beside a title and two buttons on one line. Given its own
     line it can have the width, which is what a job number wants. */
  .doccard-ref{width:100%;max-width:none}
}

@media print{
  /* On paper the boxes ARE the record, so their chrome goes and what was typed stays — the
     same treatment the JOBS sheet gets. The PDF is the intended way to send one of these;
     this is for the pilot who would rather have it on paper. */
  .doccard{break-inside:auto;border-color:#999!important}
  .doccard-head{background:none!important;border-bottom:1px solid #999!important}
  .doccard-ref{border:none!important;background:none!important;color:#000!important}
  .docsec{break-inside:avoid;border-top:1.5px solid #666!important}
  .docsec:first-of-type{border-top:none!important}
  .docsec-title{background:#eee!important;color:#000!important;border-bottom:1px solid #999!important}
  .docsec-add{display:none!important}
  .docblock{border-left:1px solid #999!important}
  .docblock-title,.docfield-lab,table.doctable th,table.doctable td.doctable-rowlab{
    background:#f2f2f2!important;color:#000!important}
  .docfield-lab{border-right:1px solid #999!important;border-bottom:1px solid #999!important}
  input.doc-in,textarea.doc-area{border:none!important;background:none!important;
    color:#000!important;resize:none!important;overflow:visible!important}
  .doctext-line{border-bottom:1px solid #999!important}
  .docchk{border-bottom:1px solid #999!important;color:#000!important}
  .docchk-box{background:none!important;color:#000!important;border:1px solid #000!important;
    width:14px!important;height:14px!important;font-size:11px!important}
  .docchk.on .docchk-txt{color:#000!important}
}