/* Back-office overrides. Empty for now: the DevExpress theme is the starting position, and this
   file exists mainly so the host has a wwwroot, without which ASP.NET Core warns at startup and
   static files are unavailable. */

/* The XAF error panel. Blazor injects this div into every page and reveals it by setting an
   inline display when a circuit throws, so it has to start hidden. Without this rule it is
   visible on a perfectly healthy page and reads as "Application Error" under the login form,
   which is the first thing anyone would report as a bug. */
#blazor-error-ui {
    background: inherit;
    bottom: 0;
    display: none;
    position: fixed;
    width: 100%;
    height: 100%;
    z-index: 100001;
}

/* The document editors get the whole width of the page.

   XAF lays a detail view out in two columns, and a rich text editor that lands in one of them is
   about 440 pixels wide. A deed's own text column is wider than that, so every line wraps twice
   and the document she is reading looks nothing like the page that will be signed. Reading a
   clause for wording is hard enough without the line breaks being wrong.

   The group is widened rather than the editor, because an editor cannot be wider than the column
   holding it. :has() keeps the rule specific to groups that actually contain a document, so the
   column of ordinary fields is left alone; the widened group drops onto its own row underneath.

   Written against the DevExpress class names rather than anything of ours, which is the weakness:
   if an upgrade renames dxreRoot the rule stops matching and the layout goes back to two narrow
   columns. That is a visible regression rather than a broken page, and the alternative is a model
   nodes generator rewriting the detail view layout, which fails less visibly when it fails. */
.dxbl-fl-group:has(.dxreRoot) {
    flex: 0 0 100%;
    max-width: 100%;
}

/* Tall enough to read several clauses without scrolling for every one. The editor sizes itself to
   its container, and the container's default is roughly a third of the screen. */
.dxbl-fl-group .dxreRoot {
    min-height: 32rem;
}

/* The client's changes, side by side.

   The panel paints its own background and its own text colour rather than inheriting the theme's.
   That is not a preference: everything below is a tint layered over this background, and a tint
   computed against one background and drawn on another is how a diff ends up as dark green on
   green.

   The text is never coloured. That was the previous version's mistake and it is the whole reason
   this was unreadable: green words on a green wash is legible enough in a screenshot of English
   monospace and not legible at all in Georgian at this size, where the letterforms are rounder and
   carry less contrast to start with. So the background says which side a row belongs to, a stronger
   patch of the same colour says which words actually moved, and the text stays at full contrast
   from top to bottom.

   Proportional rather than monospaced, unlike the unified diff this replaced. A monospace stack has
   no Georgian in it, so every deed fell through to a substitute face anyway; and a deed is prose,
   which is read faster proportionally. Alignment is the grid's job here, not the font's. */
.notary-split {
    font-family: inherit;
    font-size: 0.8125rem;
    line-height: 1.55;
    color: #e6edf3;
    background: #0d1117;
    border: 1px solid rgba(139, 148, 158, 0.35);
    border-radius: 0.25rem;
    /* Scrolls inside itself rather than stretching the page. A deed is long and the alternative is
       a detail view with a scrollbar on the whole window. */
    max-height: 32rem;
    overflow: auto;
}

/* Which column is which. Sticky, because the answer stops being obvious the moment the first
   screenful has scrolled past and both sides look like a deed. */
.notary-split-head {
    display: grid;
    grid-template-columns: 1fr 1fr;
    position: sticky;
    top: 0;
    z-index: 1;
    background: #161b22;
    border-bottom: 1px solid rgba(139, 148, 158, 0.35);
    font-weight: 600;
    color: #adbac7;
}

.notary-split-head > div {
    padding: 0.375rem 0.75rem;
}

.notary-split-head > div + div {
    border-left: 1px solid rgba(139, 148, 158, 0.35);
}

.notary-split-row {
    display: grid;
    grid-template-columns: 1fr 1fr;
}

/* Number gutter, then the paragraph. The gutter is what lets her say "the change is in 20" to
   somebody looking at the printed deed. */
.notary-split-cell {
    display: grid;
    grid-template-columns: 2.25rem 1fr;
    column-gap: 0.5rem;
    padding: 0.125rem 0.5rem;
    align-items: start;
}

.notary-split-cell.right {
    border-left: 1px solid rgba(139, 148, 158, 0.35);
}

.notary-split-number {
    text-align: right;
    color: #6e7681;
    user-select: none;
    /* Tabular figures so the gutter does not shift width between 9 and 10. */
    font-variant-numeric: tabular-nums;
}

.notary-split-text {
    /* pre-wrap, so the spacing the client typed is the spacing shown, and so a long clause wraps
       inside its own column instead of forcing the page sideways. */
    white-space: pre-wrap;
    word-break: break-word;
}

/* Context is the deed itself, carried for orientation rather than as part of the change. Dimmed
   enough to recede and not so far that it stops being readable, because the paragraph on either
   side of a change is often what tells her whether the change matters. */
.notary-split-row.context .notary-split-text {
    color: #9fa9b3;
}

/* Row washes. Only the side that actually holds the change is tinted, so an added paragraph is a
   green block with nothing opposite it, which is the shape of the fact. */
.notary-split-row.removed .notary-split-cell.left,
.notary-split-row.modified .notary-split-cell.left {
    background: rgba(248, 81, 73, 0.13);
}

.notary-split-row.added .notary-split-cell.right,
.notary-split-row.modified .notary-split-cell.right {
    background: rgba(63, 185, 80, 0.13);
}

/* The half of a row that has no paragraph, because the client added or deleted one. Marked rather
   than left blank: an empty cell reads as a paragraph that happens to be empty, and the two mean
   very different things on the screen where a deed is authorised. */
.notary-split-cell.absent {
    background: repeating-linear-gradient(
        45deg,
        rgba(139, 148, 158, 0.07),
        rgba(139, 148, 158, 0.07) 6px,
        transparent 6px,
        transparent 12px);
}

/* The words that actually moved. Stronger than the row wash, so a one-word change in a five-line
   clause is found without reading the clause. */
.notary-split-word {
    border-radius: 0.125rem;
    padding: 0 0.0625rem;
}

.notary-split-word.removed {
    background: rgba(248, 81, 73, 0.4);
}

.notary-split-word.added {
    background: rgba(63, 185, 80, 0.4);
}

/* The paragraphs that were skipped, and how many. Counted rather than silently dropped: three
   changes in a short document and three changes buried in sixty paragraphs are different documents,
   and the count is the only thing that says which one this is. */
.notary-split-gap {
    padding: 0.25rem 0.75rem;
    background: rgba(139, 148, 158, 0.09);
    border-top: 1px solid rgba(139, 148, 158, 0.2);
    border-bottom: 1px solid rgba(139, 148, 158, 0.2);
    color: #8b949e;
    font-size: 0.75rem;
    text-align: center;
    user-select: none;
}

.notary-split-empty {
    opacity: 0.7;
    font-style: italic;
}

/* ---------------------------------------------------------------------------------------------
   The client's answers.

   Same palette as the split diff above, deliberately: the two panels sit on the same screen and a
   second colour scheme between them would read as two applications. What differs is the shape. A
   diff is two columns because it compares; a sheet of answers is one column because it is read
   down, in the order the questions were put.
   --------------------------------------------------------------------------------------------- */
.notary-answers {
    font-family: inherit;
    font-size: 0.8125rem;
    line-height: 1.55;
    color: #e6edf3;
    background: #0d1117;
    border: 1px solid rgba(139, 148, 158, 0.35);
    border-radius: 0.25rem;
    /* Scrolls inside itself. A long form is forty fields, and the alternative is a detail view whose
       document panels have been pushed a screen and a half down the page. */
    max-height: 26rem;
    overflow: auto;
}

/* The grouping the notary set up on the template, printed where she put it. Sticky, because the
   heading is what tells her which part of the form she is reading once the first screenful has
   scrolled away. */
.notary-answers-heading {
    position: sticky;
    top: 0;
    z-index: 1;
    padding: 0.375rem 0.75rem;
    background: #161b22;
    border-bottom: 1px solid rgba(139, 148, 158, 0.35);
    font-weight: 600;
    color: #adbac7;
}

/* Question on the left, answer on the right, at a fixed gutter so the answers line up into a
   column the eye can run down. A proportional split would put every answer at a different left
   edge, which is what makes a two-column grid of label and value hard to scan. */
.notary-answers-row {
    display: grid;
    grid-template-columns: minmax(9rem, 16rem) 1fr;
    column-gap: 0.75rem;
    padding: 0.25rem 0.75rem;
    align-items: baseline;
}

.notary-answers-row + .notary-answers-row {
    border-top: 1px solid rgba(139, 148, 158, 0.12);
}

/* The question, dimmed. It is the constant across every submission of this template; the answer is
   the part that differs and the part being read. */
.notary-answers-label {
    color: #8b949e;
    word-break: break-word;
}

.notary-answers-value {
    /* pre-wrap so the spacing the client typed is the spacing shown, which occasionally is the
       thing being checked. */
    white-space: pre-wrap;
    word-break: break-word;
}

/* The field that names this submission in her queue. Marked so she can confirm at a glance that she
   has the right person open, which is the one check she makes on every single record. */
.notary-answers-row.identifying {
    background: rgba(88, 166, 255, 0.07);
}

.notary-answers-row.identifying .notary-answers-label {
    color: #adbac7;
    font-weight: 600;
}

/* A blank the client left, named rather than shown as nothing. An empty cell reads as a rendering
   fault; "they left this blank" is a fact about the deed and has to survive being looked at. */
.notary-answers-blank {
    color: #6e7681;
    font-style: italic;
}

/* What a later revision made of the answer. Both are shown, never one replacing the other: the
   client's word is what they consented to and the correction is what goes into the deed, and which
   one matters depends on which question is being asked. Amber rather than green, because a
   correction is not an improvement, it is a divergence from the consent record. */
.notary-answers-corrected {
    margin-left: 0.5rem;
    padding: 0 0.25rem;
    border-radius: 0.125rem;
    background: rgba(210, 153, 34, 0.16);
}

.notary-answers-arrow {
    color: #d29922;
    user-select: none;
    margin-right: 0.25rem;
}

.notary-answers-empty {
    opacity: 0.7;
    font-style: italic;
}

/* A root list view's grid stops at the bottom of the screen and scrolls inside itself.

   Virtual scrolling turned the pager off, and a DxGrid with no height constraint then grows to
   fit every row, up to ten thousand pixels: the library's hundred rows made the page itself the
   scrollbar, which defeats the point of virtualization and scrolls the toolbar away with it. The
   DevExpress guidance for virtual scrolling is exactly this, a CSS constraint on the grid.

   max-height rather than height, so a five-row grid stays five rows tall instead of stretching
   empty to the fold. The subtracted amount is the chrome above the grid: the header bar, the tab
   strip and the view's toolbar, measured on the running app rather than derived from anything.

   Root list views only; RootGridFillsThePageController applies the class. A nested grid inside a
   detail view keeps its natural height, because capping a three-row revisions grid to the
   viewport would hand it a screen of empty rows. */
.notary-root-grid {
    max-height: calc(100vh - 230px);
}

/* The AppifySheets mark in the top-left of the shell.

   background-image rather than a mask, which is the documented choice between the two: a mask
   paints the logo in the theme's current colour, which would flatten the orange and green leaves
   into one shape. The colours are the mark, so they stay.

   The selector matches the framework's own, ".header-left-side .header-logo", rather than the
   ".header-logo" the documentation names, and display is set explicitly. XAF ships that element
   hidden and sizes it from this rule, so a plain .header-logo rule loses on specificity and the
   image is inherited by something nobody can see. The framework's other rule, which hides the logo
   while the sidebar is collapsed, is left alone: that one is deliberate behaviour rather than a
   default waiting to be replaced. */
.header-left-side .header-logo {
    display: block;
    background-image: url(images/appifysheets-logo.png);
    background-position: center;
    background-size: contain;
    background-repeat: no-repeat;
    width: 28px;
    height: 28px;
}

/* -----------------------------------------------------------------------------------------------
   The answers sheet, tightened for the back office.

   The panel renders the client form's own FieldSections component, which is the point: the notary
   reads the answers laid out exactly as the client was asked them, so a question about "the third
   box" means the same thing to both of them. What does not carry over is the spacing. Those sizes
   were chosen for one person filling in a form on a phone, where a large label and a roomy row are
   what make it usable; here the same rules put four fields on a screen and pushed the deed below
   the fold.

   Only the spacing is touched. The structure, the grouping into party boxes and the order stay as
   the client saw them, and the client form is not affected: every rule is scoped to the panel.
   --------------------------------------------------------------------------------------------- */
.notary-answers .field-group {
    margin: 0.5rem 0;
    padding: 0.25rem 0.7rem 0.45rem;
}

.notary-answers .field-group legend {
    font-size: 0.7rem;
}

.notary-answers .field-grid {
    column-gap: 0.9rem;
}

.notary-answers .field,
.notary-answers .field-grid .field,
.notary-answers .field:first-of-type {
    padding: 0.2rem 0;
}

/* The label at reading size rather than form size, and above its box rather than shouting over it.
   This is the rule that was costing the most: a caption set for a phone, on forty rows. */
.notary-answers .field label {
    font-size: 0.8125rem;
    font-weight: 500;
    margin-bottom: 0.15rem;
}

/* The client's original value under a correction. Small on purpose: it is there to be found when
   looked for, not to compete with the value that goes into the deed. */
.notary-answers .field .field-note,
.notary-answers .field .help {
    margin: 0.1rem 0 0;
    font-size: 0.75rem;
}