/* ==========================================================================
   Foundation rich text content (AB#99067, analysis section 9.1)
   --------------------------------------------------------------------------
   Loaded by masterFoundation.cshtml only. Every rule is scoped under
   .brand-foundation (the Foundation body class) AND #pageBody (the wrapper the
   Foundation views put rich text output into), so nothing here can reach the
   ASISA, ESD or Academy layouts even where they render the same shared partial.

   main.css is NOT modified. That matters more here than in most components:
   the rules this file overrides (p a, ul, ol, #pageBody p img,
   .CIfoundationProgrammes li::before) are shared by all four entity sites, and
   .CIfoundationProgrammes in particular is also used by AcademyProgrammesPage.

   Do not be fooled by the class names. .foundationProgrammesPage,
   .CIfoundationProgrammes, .foundationRTE and .foundationTemplate all read as
   Foundation scopes and none of them are. .brand-foundation on <body> is the
   only reliable one.

   What the story asks for (31 Aug 2026 handover, transcripts in the BOK at
   asisa/transcripts/handover/):
     - links in body copy are bold and not underlined [part 1, 1:36:17]
     - bullet and list styling is fixed in the editor configuration and the
       site CSS, never per page [part 1, 1:33:34]
     - media uploaded through the editor gets the corner treatment
       [part 1, 1:25:12]
     - left and right image wrap keeps working [part 2, 27:43]

   Design source: NONE. There is no Figma frame or crop for Foundation body
   copy: design/ holds references for the navigation, breadcrumb, social links,
   latest news and image gallery only, and the project's Figma seat is a View
   seat whose monthly call budget is already spent (see
   design/foundation-rich-text/SOURCE.md). Every value below is therefore either
   INHERITED from a shared rule that already ships, or an ESTIMATE named as such.
   Nothing here is invented where the transcript is silent: link hover in
   particular is deliberately left alone. See SOURCE.md for the open list.
   ========================================================================== */

.brand-foundation {
  /* All four corners, not the gallery's three-plus-a-square. The gallery's
     square top right exists only because the accent triangle's right angle sits
     in it and rounding clipped the tip (foundation-image-gallery.css, and
     Michiel reported it on dev on 8 September 2026). A rich text image carries
     no triangle, so the asymmetry would have nothing behind it. Value matched
     to --fnd-gallery-radius so editor-placed images and gallery images agree.
     Decision recorded on the story, 8 September 2026. */
  --fnd-rte-image-radius: 24px;
}

/* --------------------------------------------------------------------------
   Links in body copy (AC: bold, never underlined)
   --------------------------------------------------------------------------
   The shared rule at main.css "p a, h1 a, h2 a, h3 a, .moreinfo a, li a,
   .introLink a, .umb-grid a span" already sets font-weight 700 and
   text-decoration none !important. The visible underline is NOT a text
   decoration: it is border-bottom: 2px solid var(--text). A rule that only set
   text-decoration: none would therefore change nothing at all on screen. The
   border is what has to go.

   font-size and line-height are reset to inherit on purpose. The shared rule
   drops a link to 0.875rem/1.625rem while the paragraph around it is
   16px/26px, so a link currently renders two pixels smaller than the sentence
   it sits in. Janelle described the intended difference as "bold versus not
   bold as a link... very subtle" [part 1, 1:36:17], which a size change is not.

   COLOUR IS DELIBERATELY NOT SET. It was set to inherit, and that was a defect
   Lonwabo Mnyaiza caught in review on 9 September 2026. Five Foundation views
   paint rich text links in the page's programme colour from an inline <style>
   block: FoundationFAQPage:20, FoundationsProgrammesPage:27,
   RichTextEditorContentPageWithIntro:20,
   RichTextEditorContentPageWithQuickLinks:23 and
   CarouselContentPageWithQuickLinks:21, each through
   ColourUtils.GetColourStyle, which emits a literal "color: #<hex>". None of
   those selectors carries an id, so every rule in this file outranks them, and
   "color: inherit" silently stripped the programme sub-brand identity from
   every link on a programme page. Saying nothing about colour leaves both
   cases right: main.css's var(--text) still applies where no programme colour
   is set, and the programme colour still applies where one is. Weight is the
   difference the story asked for either way.

   Weight alone still satisfies WCAG 1.4.1, because it is a non-colour cue.

   Headings are NOT in this rule. Their text is already weight 700, so weight
   cannot be the cue there. See the heading rule below.

   The selectors name p, li and table cells rather than resetting
   "#pageBody a" wholesale, and that is deliberate. AB#99013 lost a debugging
   pass to exactly that shape: a wrapper-level descendant reset outranks the
   single-class rules a component uses for its own links, and silently strips
   their size and weight. Checked on this branch on 8 September 2026: across the
   22 Foundation views and the 32 #pageBody blocks in them, no block contains a
   view component, a partial or a link carrying its own class, and of the five
   shared partials that emit #pageBody, the call-to-action buttons in
   MainLandingPageContent sit directly in a div (so no rule here matches them)
   and the button in MediaLandingPageIntroduction is outside the wrapper
   altogether. Grid rich text cells DO fall inside it and are meant to: a link
   an editor types in a grid cell should look like one they type anywhere else.

   If a component is ever placed inside #pageBody with its own links in a p or
   li, give those links a class and clear these properties on it, rather than
   loosening the selectors here.
   -------------------------------------------------------------------------- */

.brand-foundation #pageBody p a,
.brand-foundation #pageBody li a,
.brand-foundation #pageBody td a,
.brand-foundation #pageBody th a {
  border-bottom: 0;
  text-decoration: none;
  font-weight: 700;
  font-size: inherit;
  line-height: inherit;
}

/* --------------------------------------------------------------------------
   Links inside a heading KEEP an underline
   --------------------------------------------------------------------------
   "Bold, not underlined" is a body copy decision and it cannot carry into a
   heading, because main.css already sets h1, h3, h4 and h6 to font-weight 700
   and h5 to 500. Take the border off a link in one of those and it computes
   identically to the heading text around it: same colour, same weight, same
   size, no underline. There is then no cue at all, which fails WCAG 1.4.1, and
   H3 is one of the two levels this story ships, so an editor applying
   "Subsection header" to a line holding a link would produce exactly that.
   Lonwabo Mnyaiza raised this in review on 9 September 2026.

   All six levels are covered, not the four the body copy rule used to name.
   main.css's shared link rule stops at h3, so a link inside an h4, h5 or h6
   gets nothing but "a { text-decoration: none }" today and is ALREADY
   indistinguishable from its heading. This rule fixes that too.

   currentColor rather than var(--text) so the underline follows whatever
   colour the link ends up with, including a programme colour, instead of being
   pinned to a token that a programme page does not use. font-size and
   line-height are still normalised, because main.css shrinks a link inside a
   48px h1 to 0.875rem.

   font-weight is deliberately left alone. Inside h2 (weight 400) main.css
   makes the link 700, which is a second cue worth keeping; inside the rest the
   heading is already 700 and weight can add nothing.

   TWO LINK KINDS ARE EXCLUDED, because this rule ADDS a border rather than
   removing one, so unlike the body copy rule above it can give a link
   something it deliberately does not have. Both exclusions are one-class
   selectors that main.css relies on outranking its own "h1 a, h2 a, h3 a"
   rule, and (1,1,2) beats (0,1,0):
     - .imageLinks, added by rteAnchorTags.js:39 to any "#pageBody a" holding
       an img. main.css:348 clears its border so a linked image is not underset
       by a rule; without this exclusion a linked image inside a heading would
       gain a 2px line it does not have today.
     - .downloadIcons, main.css:549, "border: none" plus a background icon.
       Its span keeps its own white border at main.css:572, which the span rule
       above deliberately leaves alone, so a download link inside a heading
       would otherwise draw two borders.
   Lonwabo Mnyaiza raised both on re-review, 9 September 2026. Rare in practice,
   which is exactly why a rule would have shipped without anyone seeing it.
   -------------------------------------------------------------------------- */

.brand-foundation #pageBody h1 a:not(.imageLinks):not(.downloadIcons),
.brand-foundation #pageBody h2 a:not(.imageLinks):not(.downloadIcons),
.brand-foundation #pageBody h3 a:not(.imageLinks):not(.downloadIcons),
.brand-foundation #pageBody h4 a:not(.imageLinks):not(.downloadIcons),
.brand-foundation #pageBody h5 a:not(.imageLinks):not(.downloadIcons),
.brand-foundation #pageBody h6 a:not(.imageLinks):not(.downloadIcons) {
  border-bottom: 2px solid currentColor;
  text-decoration: none;
  font-size: inherit;
  line-height: inherit;
}

/* A link whose text an editor wrapped in a span. main.css gives "#pageBody a
   span" its own copy of the border and the smaller size, so the reset has to
   reach it too.

   Download links are excluded on purpose. rteAnchorTags.js adds
   .PDFIcon/.XLSIcon/.ZIPIcon/.DOCIcon plus .downloadIcons to any .pdf, .xls,
   .zip or .doc link and moves its text into a span, and main.css then gives
   that combination a deliberate treatment of its own: a background icon, a
   24px indent to clear it and "font-size: 19px !important". That is a download
   affordance, not body copy, and this story does not change it. Measured on
   dev on 8 September 2026: a download link renders identically with and
   without this stylesheet.

   Colour is left alone here for the same reason as above, and one more:
   main.css gives ".umb-grid a span" var(--text) explicitly, so setting inherit
   would have repainted a spanned link in a grid cell on a programme page. Not
   setting it keeps that case exactly as it renders today. */
.brand-foundation #pageBody a:not(.downloadIcons) span {
  border-bottom: 0;
  font-size: inherit;
  line-height: inherit;
}

/* Hover is deliberately NOT set here.
   a:hover in main.css is an empty rule, so there is no hover treatment on the
   site today. The story asks for hover states to be "verified against the
   Figma", and they cannot be: there is no cached frame for body copy and the
   Figma budget is spent. Janelle's own recollection was unsure ("I must just
   double check", part 1 [1:35:00]) before she settled on bold at [1:36:17].
   Guessing one would be inventing design. Open item, see SOURCE.md. */

/* --------------------------------------------------------------------------
   Lists (AC: bullet and list styling comes from the configuration, not the page)
   --------------------------------------------------------------------------
   Bulleted lists currently come out differently depending on which wrapper
   classes a page happens to carry:
     - main.css sets list-style: none on ul for five wrapper classes
       (.foundationProgrammesContent, .carouselContentPageWithQuickLinksPage,
       .rteContentPageWithIntroPage, .rteContentPageWithQuickLinksPage,
       .FAQAccordion), but not on ol
     - .CIfoundationProgrammes ul li::before then supplies a bullet, so pages
       carrying BOTH look right and pages carrying only the first lose their
       markers entirely

   Ordered lists are NOT part of that problem, and an earlier version of this
   comment said they were. main.css:3497 (.CIfoundationProgrammes ol li::before)
   sets font-weight, display, width and margin but no content, and a pseudo
   element with no content is never generated, so it has never painted anything
   and there is no empty box beside a number. Numbers render today from the
   native marker, because main.css removes list-style from ul only. The ol rule
   below therefore restates what already happens, and is here so the pair reads
   as one decision rather than leaving a reader to work out why only ul is
   named. Corrected after Lonwabo Mnyaiza spotted the contradiction with the
   ::before note further down, 9 September 2026.

   One predictable result for every Foundation page, set once, is exactly what
   "never per-page fixes" [part 1, 1:33:34] asks for. Native markers are used
   rather than generated content so that ordered lists number themselves and
   screen readers still announce a list.

   Indentation is deliberately NOT set. There is no design reference for body
   copy (design/foundation-rich-text/SOURCE.md), and an invented indent would
   move every existing Foundation list for no stated reason. Leaving the
   browser default in place means a page that renders correctly today keeps its
   layout to the pixel, and a page that was silently losing its markers gains
   them in the same position. Set an indent here only when a design says what
   it should be.
   -------------------------------------------------------------------------- */

.brand-foundation #pageBody ul {
  list-style: disc outside;
}

.brand-foundation #pageBody ol {
  list-style: decimal outside;
}

/* Suppress the shared generated bullet so we never render two. The shared rules
   are left in place for ASISA, Academy and ESD.

   The ol half of this selector is belt and braces, not a fix: the shared
   ol li::before sets no content today, so nothing of it is generated. It is
   named so that adding content to that shared rule later cannot put a second
   marker beside a Foundation number without anyone noticing.

   THE PROGRAMME COLOUR MOVES WITH THE MARKER, it is not dropped. The same five
   Foundation views that colour links also emit an unscoped
   "ul li::before { color: #<hex> }", so suppressing the pseudo-element here
   would have turned a programme-coloured bullet into a native disc in
   var(--text). Lonwabo Mnyaiza raised that in review on 9 September 2026. Each
   of those views now carries a "#pageBody ul li::marker" rule beside its
   ::before rule, which paints the native marker the same colour. It is scoped
   to #pageBody, which is narrower than the ::before rule it accompanies, so it
   cannot reach a navigation or footer list.

   Ordered lists are deliberately not coloured. Their numbers render today from
   the native marker in var(--text), because main.css only removes list-style
   from ul, and the shared "ol li::before" rule sets no content so nothing of
   it ever painted. Colouring them now would be a new decision, not a rescue. */
.brand-foundation #pageBody ul li::before,
.brand-foundation #pageBody ol li::before {
  content: none;
}

/* --------------------------------------------------------------------------
   Images placed through the editor (AC: media gets the corner treatment)
   --------------------------------------------------------------------------
   The editor emits <p><img></p>, never <figure>, confirmed by the existing test
   FoundationLatestNewsRichTextTests.An_image_alone_is_content_the_editor_placed.
   main.css already gives that image "margin: 5px 25px; max-width: 90%", which
   is what makes a left or right wrapped image sit off the text. Those are left
   untouched so image wrap keeps behaving [part 2, 27:43]; only the corners are
   added. Radius on the img itself clips the picture, so no overflow wrapper is
   needed and a floated image is unaffected.
   -------------------------------------------------------------------------- */

.brand-foundation #pageBody p img,
.brand-foundation #pageBody p a img {
  border-radius: var(--fnd-rte-image-radius);
}
