/* ===========================================================================
   Grape scope (W-51)

   Constructs produced by the GrapesJS editor that the GOV.UK Design System has
   no opinion about, because no hand-authored GDS page ever contains them:
   layout tables carried over from an email, editor row and cell divs, and
   rich-text lists that Froala never produced in this shape.

   Three rules govern everything in this file.

   1. EVERY selector is scoped under .gds-grape. A suite that does not pass
      wrapper-class="gds-grape" to <gds-content-page> cannot be affected by
      anything here, and that is checked by test rather than assumed.

   2. ONE typography declaration, on the scope root, and it is the EMAIL's.
      No other rule in this file states a face, a size or a colour, except
      the focus rule below where the colour IS the control.

      This said "STRUCTURAL ONLY, no font-family, no font-size" for two
      different reasons in succession, and both have now gone.

      The first was that email typography is removed at the adapt step so
      .govuk-body governs. W-63 reversed that: the adapt step leaves the
      author's face and size alone and the content wrapper takes
      govuk-body="false".

      The second was written after W-63 and said a font declaration here
      would compete with the authored content. It would not, and that was
      the mistake. An inline style beats a class selector, and every block
      the editor emits declares its own font inline, so a rule on the scope
      root can only supply a value where the content supplies none. It
      completes rather than competes - which is the distinction the old
      wording itself drew and then applied backwards.

      What W-63 actually left behind was a hole. govuk-frontend sets no
      font-family or font-size on html, body, .govuk-template or
      .govuk-template__body: its typography comes from its classes and
      nowhere else. Taking .govuk-body off the wrapper therefore left
      anything without an inline font falling to the browser's defaults -
      a serif face and roughly 1.2 line-height, against the email's Arial
      at 16px/1.5625. ho-extensions.css covers a bare <p> and a bare
      heading with a family and nothing else, so div, li, td and span had no
      face at all and nothing had the right line-height.

      The values below are the ones the delivered message uses, copied from
      the <body> of the GDS email wrapper. That is the point: this is not a
      design system baseline, it is the email's, because a landing page has
      to display as the email it came from.

   3. NO !important. If a rule here needs it, the adapt step has not done its
      job and that is where the fix belongs.

   It lives in the shared library rather than in the DMS portal so the next
   suite to adopt the editor inherits it instead of copying it.
   =========================================================================== */

/* ---------------------------------------------------------------------------
   The baseline, and the only typography in this file.

   Copied from the <body> of the GDS email wrapper (the seed in
   DMS.Database/dbo/Data/RunEveryTime/GdsEmailTemplate.data.sql), so unstyled
   text reads the same on the landing page as it does in the inbox. A test
   asserts the two stay identical; they are two statements of one value and that
   is a drift risk worth guarding rather than hiding.

   On the scope root, so it inherits and nothing has to be enumerated. Every
   block the editor emits declares its own font inline and an inline style beats
   a class selector, so this reaches only what the content left unsaid - which,
   after W-63, was div, li, td and span entirely, and the line-height of
   everything including <p>.

   Scoped like every other rule here: a portal that does not emit .gds-grape
   cannot see it, and only the two DMS landing routes and the DMS approvals
   preview do. SelectorInertnessTests enforces both halves against the working
   tree, so this cannot reach the other suites by accident.
   --------------------------------------------------------------------------- */
.gds-grape {
    font-family: Arial, 'Helvetica Neue', Helvetica, sans-serif;
    font-size: 16px;
    line-height: 1.5625;
    color: #0b0c0c;
}

/* ---------------------------------------------------------------------------
   Layout tables and editor rows from the email channel.

   W-63. Two things used to live here. A media query stacked every presentation
   table's cells below the GOV.UK breakpoint, so two columns that read well on a
   desktop did not become two ribbons on a phone; and .gjs-row / .gjs-cell were
   forced to display: block, to reflow the row that the adapt step had just
   unpicked. Both were the web behaviour an email cannot have, and that is
   exactly why they have gone: a landing page is now required to display as the
   email it came from, at every width.

   The adapt step no longer strips the CSS table display either, so a row holds
   together here as it does in the email. Overriding it from this file would put
   the difference straight back. The empty-cell rule went the same way: an empty
   cell still occupies its column in an email, and collapsing it here would shift
   everything beside it.

   What remains is the guard against a table forcing the page wider than the
   device. That one is not a difference between the channels: a mail client
   scales the whole message down to fit and a browser has no equivalent, so
   without it the page simply scrolls sideways.

   The cost of all this is set out in LandingAdapter's class summary. Reflow on a
   narrow screen is what was given up, and WCAG 1.4.10 is the criterion covering
   it.
   --------------------------------------------------------------------------- */
.gds-grape table[role="presentation"] {
    max-width: 100%;
}

/* ---------------------------------------------------------------------------
   Lists: none, deliberately.

   This file used to give every list GOV.UK-like spacing - 20px indent, nothing
   above, 20px below, 5px under each item - which the email has no equivalent
   of. A list keeps the spacing its template gives it in both channels, and
   where the template gives none, the email shows the browser's (40px indent,
   16px above and below, nothing between items) and the landing page showed
   these. 10 October 2026, the editor's preview of a template whose list
   states no spacing: "when previewing the email and the landing page the
   bullet point alignment is not the same" - 40px against 20px. And the 5px
   reached even lists that state their own spacing, since a template rarely
   states a margin on each item. Measured (scratchpad listcompare.cjs) at 1000
   and 375px on a bare list, the editor's baseline list and an author-spaced
   list: with these rules gone, indent, gaps and item spacing match the email
   in all three. Like the table and display rules W-63 removed, the parity
   decision is that a landing page displays as the email it came from.
   --------------------------------------------------------------------------- */

/* ---------------------------------------------------------------------------
   Focus.

   The custom button is an <a> carrying inline presentation, so it has no
   GOV.UK focus state and falls back to whatever the browser draws, which
   differs on every engine and in some cases is nothing at all. Anything
   focusable inside authored content gets the standard GDS focus treatment.

   :focus-visible rather than :focus, so a pointer click does not leave a
   focus ring behind on an element the user has already finished with.
   --------------------------------------------------------------------------- */
.gds-grape a:focus-visible,
.gds-grape button:focus-visible,
.gds-grape [tabindex]:focus-visible {
    outline: 3px solid var(--govuk-focus-colour, #fd0);
    outline-offset: 0;
    background-color: var(--govuk-focus-colour, #fd0);
    color: #0b0c0c;
    box-shadow: 0 -2px var(--govuk-focus-colour, #fd0), 0 4px #0b0c0c;
    text-decoration: none;
}

/* ---------------------------------------------------------------------------
   Images.

   Editor content can carry an explicit pixel width from the email channel.
   On a narrow viewport that width would overflow the page, and the adapt step
   deliberately keeps the attribute because the browser uses it to reserve
   space before the image loads.
   --------------------------------------------------------------------------- */
.gds-grape img {
    max-width: 100%;
    height: auto;
}