/*
    THE EMAIL TEMPLATE EDITOR'S OWN STYLESHEET.

    Linked from App.razor, because the editor is a dialog three screens open - the platform's email
    templates, a firm's, and the send that puts a firm's documents in front of a client - and a
    component rendered from several places cannot know whether its file is already there. It holds
    what only those screens draw: the two halves, the height of the message box, the insert row
    under it, and the sheet the message is previewed on.

    WHAT IT DOES NOT OWN. The fields, the buttons, the notice, the segmented control, the token list
    and the type scale are utilities.css's, SegmentedFilter's and the token picker's; nothing here
    restates a face.
*/

/* ── The two halves ────────────────────────────────────────────────────────
   THE FORM BESIDE THE MESSAGE, at the width the message is actually read in.

   THE PANE IS WIDER THAN THE MESSAGE, AND THAT IS THE WHOLE POINT. The frame is a 600px table with
   a media query at 620px, so a pane of exactly 600 is a viewport under the breakpoint and draws the
   PHONE layout - to an author who has just pressed Desktop. What a desktop mail client gives a
   message is a reading pane with room either side of it, which is what 700 is: over the breakpoint,
   so the fixed layout holds and the page ground shows at both edges exactly as it does in an inbox.

   The form takes what is left, and the pair stacks where the pane could no longer have its 700 -
   at which point the message is read ABOVE the form, at a shorter height, because a preview that
   pushed every field below the fold would be a live preview nobody could type under.
   ────────────────────────────────────────────────────────────────────────── */

.sv-emailtpl {
  display: grid;
  grid-template-columns: minmax(0, 1fr) 700px;
  gap: var(--sv-space-5);
  align-items: start;
}

.sv-emailtpl__form,
.sv-emailtpl__side {
  min-width: 0;
}

@media (max-width: 1200px) {
  .sv-emailtpl {
    grid-template-columns: minmax(0, 1fr);
  }

  .sv-emailtpl__side {
    order: -1;
  }

  .sv-emailtpl__paper,
  .sv-emailtpl__plain {
    height: clamp(260px, 34vh, 380px);
  }
}

/* THE MESSAGE BOX IS TALL ENOUGH TO HOLD A MESSAGE. A textarea's default is two lines, which is
   right for a note and wrong for the one field this dialog exists to edit. */
.sv-emailtpl__body {
  min-height: 220px;
  resize: vertical;
}

/* ── The insert row ────────────────────────────────────────────────────────
   THE CONTROL AND THE SENTENCE SAYING WHERE IT WRITES, on one line under the boxes it fills. The
   sentence changes as somebody moves between the subject, the message and the button, so it is
   beside the control rather than under it: a note that moves the button it explains would read as
   the form twitching.
   ────────────────────────────────────────────────────────────────────────── */

.sv-emailtpl__insert {
  display: flex;
  align-items: center;
  gap: var(--sv-space-3);
  flex-wrap: wrap;
}

.sv-emailtpl__insert-note {
  margin: 0;
  min-width: 0;
  font: 400 12px/1.45 var(--sv-font-sans);
  color: var(--sv-text-tertiary);
}

/* ── The preview ───────────────────────────────────────────────────────────
   WHAT IS SHOWN IS THE MESSAGE ITSELF, in a frame of its own, so everything about how it looks is
   BrandedEmailBody's and nothing about it is this stylesheet's. What is here is the reading pane
   around it: how tall it stands, what it is set on, and the two widths it is read at.
   ────────────────────────────────────────────────────────────────────────── */

.sv-emailtpl__toolbar {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: var(--sv-space-3);
  flex-wrap: wrap;
  margin-bottom: var(--sv-space-2);
}

/* THE REGION RESETS THE CONTROL'S SPACING, never the caller: the segmented control owns a bottom
   margin where it heads a list, and inside a centred row that margin lifts it half of itself above
   the label beside it. The same reset `.sv-card__toolbar` makes, for the same reason. */
.sv-emailtpl__toolbar .sv-segmented {
  margin-bottom: 0;
}

/* A READING PANE, BOUNDED AND SCROLLING ITSELF. A message runs to whatever length its author wrote,
   and a preview that grows with it pushes the test-send control - the one thing on this side that
   acts - past the bottom of the dialog on a long note. Bounded to the height of a mail client's
   own pane, which is what this is.

   THE SURFACE IS `.sv-card--flush`'S AND IS WORN, NOT RESTATED. A raised fill, a bordered box, a
   card radius and `overflow: hidden` together ARE that card, and a file writing all four is drawing
   it under a second name - which is what `SectionSurfaceGuardTests` refuses. What is this pane's
   own is its height and the two widths it is read at. */
.sv-emailtpl__paper {
  height: clamp(340px, 54vh, 620px);
}

/* THE TWO WIDTHS ARE THE TWO SIDES OF THE FRAME'S OWN MEDIA QUERY, not a second opinion about how
   a message reflows. Wide is the pane, which stands over the 620px breakpoint so the fixed layout
   holds; phone is under it, so the frame goes fluid on its own. */
.sv-emailtpl__paper--wide {
  width: 100%;
}

.sv-emailtpl__paper--phone {
  width: 390px;
  max-width: 100%;
  margin: 0 auto;
}

.sv-emailtpl__frame {
  display: block;
  width: 100%;
  height: 100%;
  border: 0;
}

/* THE PART A TEXT-ONLY CLIENT GETS, set in the measured face because it is what it is: characters
   in columns, with the author's own line breaks and nothing else. It wears `.sv-card` for its
   surface and its padding, so what is here is the same bounded height the frame beside it takes -
   a preview that changed size as somebody switched between the two would read as the dialog
   jumping rather than as one message shown two ways. */
.sv-emailtpl__plain {
  height: clamp(340px, 54vh, 620px);
  margin: 0;
  overflow: auto;
  color: var(--sv-text-secondary);
  font: 400 12px/1.6 var(--sv-font-mono);
  white-space: pre-wrap;
  overflow-wrap: anywhere;
}