/* ============================================================
   Blog Content Styles — extracted from community.backrr.com
   Scoped to .blog-content class
   ============================================================ */

.blog-content {
  max-width: 1200px !important;
  margin: 0 auto !important;
  /* No side padding here — the wrapper in article-page.tsx (px-6 / lg:px-10)
     already provides it. This was adding a second, redundant 24px on top of
     that on every screen size, making the content column noticeably
     narrower than it needed to be — exactly the "spacing on sides" feedback. */
}

.blog-content,
.blog-content *:not(code):not(pre):not(kbd):not(samp) {
  font-family: var(--font-body), "Lato", sans-serif !important;
}

/* Re-assert mono for code, including spans CKEditor may nest inside it —
   handled as its own rule rather than as a `:not(code *)` above. */
.blog-content code,
.blog-content pre,
.blog-content code *,
.blog-content pre * {
  font-family: "Fragment Mono", monospace !important;
}

/* ── Smooth scroll + heading offset ──────────────────────── */

html {
  scroll-behavior: smooth !important;
}

.blog-content h1,
.blog-content h2,
.blog-content h3,
.blog-content h4,
.blog-content h5,
.blog-content h6 {
  scroll-margin-top: 100px !important;
  margin-block: 1rem 0.5rem !important;
  letter-spacing: 0rem !important;
}

/* Word/CKEditor pastes can put inline size/weight directly on a heading tag, or
   on a <span>/<strong> nested inside it (same pattern we hit with the table
   headers). Every heading — and everything inside it — is forced to the site's
   own size/weight/family so headings are identical across every post.

   Colour included: headings are #7b2fbe in 51 places across the blog and other
   near-blacks elsewhere, so leaving it to the document meant the heading colour
   changed from post to post. `inherit` sends every span back to the heading's
   own colour, which is the black below. Weight is untouched by this — headings
   stay bold. */
.blog-content h1 *,
.blog-content h2 *,
.blog-content h3 *,
.blog-content h4 *,
.blog-content h5 *,
.blog-content h6 * {
  color: inherit !important;
  font-family: inherit !important;
  font-size: inherit !important;
  font-weight: inherit !important;
  background-color: transparent !important;
}

/* ── Typography: Headings ─────────────────────────────────── */

.blog-content h1 {
  font-family: var(--font-body), "Lato", sans-serif !important;
  font-size: 30px !important;
  font-weight: 700 !important;
  letter-spacing: -2.12px !important;
  line-height: 40px !important;
  color: #000 !important;
  text-align: left !important;
  margin: 0 !important;
}

.blog-content h2 {
  font-family: var(--font-body), "Lato", sans-serif !important;
  font-size: 24px !important;
  font-weight: 700 !important;
  letter-spacing: 0.02em !important;
  line-height: 34px !important;
  color: #000 !important;
  text-align: start !important;
  margin: 0 !important;
  padding-top: 10px !important;
}

.blog-content h3 {
  font-family: var(--font-body), "Lato", sans-serif !important;
  font-size: 20px !important;
  font-weight: 600 !important;
  letter-spacing: 0em !important;
  line-height: 30px !important;
  color: #000 !important;
  text-align: start !important;
  margin: 0 !important;
  padding-top: 10px !important;
}

.blog-content h4 {
  font-family: var(--font-body), "Lato", sans-serif !important;
  font-size: 18px !important;
  font-weight: 600 !important;
  letter-spacing: -1px !important;
  line-height: 27px !important;
  color: #000 !important;
  margin: 0 !important;
}

.blog-content h5 {
  font-family: var(--font-body), "Lato", sans-serif !important;
  font-size: 16px !important;
  font-weight: 600 !important;
  letter-spacing: 0em !important;
  line-height: 24px !important;
  color: #000 !important;
  margin: 0 !important;
}

.blog-content h6 {
  font-family: var(--font-body), "Lato", sans-serif !important;
  font-size: 14px !important;
  font-weight: 600 !important;
  letter-spacing: 0px !important;
  line-height: 20px !important;
  color: #000 !important;
  margin: 0 !important;
}

/* ── Typography: Paragraphs ───────────────────────────────── */

.blog-content p {
  font-family: var(--font-body), "Lato", sans-serif !important;
  font-size: 20px !important;
  font-weight: 400 !important;
  letter-spacing: -0.02em !important;
  line-height: 1.75rem !important;
  color: #000 !important;
  margin: 0 !important;
  margin-bottom: .5rem !important;
}

/* Paragraph/list runs are forced black like everything else. The documents
   carry #222222 in 229 places, #333333 in 38, and #7b2fbe in 30 — so body copy
   arrived in a different shade depending on which doc it came from, and the odd
   sentence came through purple. `inherit` sends every span back to the
   paragraph's own colour, which is the black above.

   Emphasis is unaffected: bold and italic come from the <strong>/<em> rules
   below, so a run that loses its purple stays bold.

   Background is forced for the same reason: Word carries highlight fills
   through the paste, and a stray coloured block behind one sentence is not a
   choice anyone made on purpose. */
.blog-content p *,
.blog-content li * {
  color: inherit !important;
  background-color: transparent !important;
  font-size :20px !important;
}

.blog-content p+p {
  margin-top: 20px !important;
}

/* Paragraph spacing after headings */
.blog-content h2+p,
.blog-content h3+p,
.blog-content h4+p,
.blog-content h5+p,
.blog-content h6+p {
  margin-top: 10px !important;
}

/* ── One format for every post ─────────────────────────────────
   CKEditor faithfully keeps whatever the source document carried, so without
   these the same paragraph renders differently from post to post. Measured
   across the blog: 11 of 17 posts put an inline font-size on their spans, in
   five different values (10pt, 10.0pt, 11pt, 12pt, 14pt) — the inline style
   wins over `.blog-content p`, so body copy lands anywhere between 13px and
   20px depending on which document it was pasted from.

   Sizing is therefore taken from the block, which the rules above define, and
   nothing inside a paragraph gets to set its own. code keeps its own size. */
.blog-content p *:not(code),
.blog-content li *:not(code),
.blog-content blockquote *:not(code) {
  font-size: inherit !important;
  line-height: inherit !important;
}

/* Word nests the runs inside <strong>/<em> in spans carrying font-weight:400
   and font-style:normal, which silently cancels the emphasis the author
   applied. Emphasis is decided by the tag, not by the pasted span. */
.blog-content strong,
.blog-content strong *,
.blog-content b,
.blog-content b * {
  font-weight: 700 !important;
}

.blog-content em,
.blog-content em *,
.blog-content i,
.blog-content i * {
  font-style: italic !important;
}

/* Image captions — the centered paragraph directly after a figure. They were
   ~13px grey in the source and are now inheriting 20px body copy, so they read
   as another paragraph. Matched on the centering rather than on `figure + p`
   alone, so an ordinary paragraph that happens to follow an image is not
   shrunk into a caption. */
.blog-content figure + p[style*="center"],
.blog-content figure + p[style*="center"] * {
  font-size: 15px !important;
  line-height: 1.5 !important;
  color: var(--color-muted, #69756f) !important;
  text-align: center !important;
}

/* ── Typography: Links ────────────────────────────────────── */

.blog-content a {
  color: var(--color-leaf-deep, #36b85f) !important;
  text-decoration: underline !important;
  transition: color 0.7s cubic-bezier(0.4, 0, 0, 1),
    text-decoration-color 0.7s cubic-bezier(0.4, 0, 0, 1) !important;
}

.blog-content a:hover {
  color: #000 !important;
  text-decoration: none !important;
}

/* ── Typography: Strong / Em ──────────────────────────────── */

.blog-content strong {
  font-weight: 700 !important;
}

.blog-content em {
  font-style: italic !important;
}

/* ── Lists ────────────────────────────────────────────────── */

.blog-content ol,
.blog-content ul {
  font-family: var(--font-body), "Lato", sans-serif !important;
  font-size: 20px !important;
  font-weight: 400 !important;
  letter-spacing: -0.02em !important;
  line-height: 1.75em !important;
  color: #000 !important;
  padding-left: 1.5em !important;
  margin: 10px 0 !important;
}

.blog-content li {
  margin-bottom: 6px !important;
}

.blog-content li p {
  margin: 0 !important;
}

/* ── Tables ───────────────────────────────────────────────── */

.blog-content table {
  /* Gradient outer frame. border-image would be the obvious tool, but it
     silently disables border-radius — so instead the border is made
     transparent and the ramp is painted as a background layer clipped to the
     border box, with a flat paper layer clipped to the padding box covering
     everything inside it. That keeps the 10px radius below intact. The border
     must stay transparent for the ramp underneath it to show. */
  border: 3px solid transparent !important;
  background-image:
    linear-gradient(var(--color-paper), var(--color-paper)),
    linear-gradient(135deg, var(--color-leaf), var(--color-teal), var(--color-sky)) !important;
  background-origin: border-box !important;
  background-clip: padding-box, border-box !important;
  border-radius: 10px !important;
  overflow: hidden !important;
  border-collapse: separate !important;
  border-spacing: 0 !important;
  /* auto (not fixed): the actual desktop overflow was the <figure>'s inline
     width, the per-cell inline widths, and the <table>'s inline margin-left —
     all neutralized separately below/above. "fixed" was an extra safeguard
     that turned out unnecessary, and it force-divides columns into equal
     shares — on a ~380px phone that crams a 3–4 column table into unreadably
     narrow columns. "auto" lets column widths follow their content instead,
     which is what a narrow table needs to stay readable. */
  table-layout: auto !important;
  word-break: normal !important;
  width: 100% !important;
  /* Word/CKEditor also puts an inline margin-left (e.g. 7.0pt) on <table> —
     without !important that shifted the 100%-wide table past its container
     on the right, which is what was actually being clipped/scrolled. */
  margin: 0px 0px 20px 0px !important;
}

.blog-content table col {
  width: auto !important;
}

.blog-content th,
.blog-content td {
  background-color: #fff !important;
  padding: 10px !important;
  font-family: var(--font-body), "Lato", sans-serif !important;
  font-size: 16px !important;
  line-height: 1.4em !important;
  color: #000 !important;
  text-align: left !important;
  vertical-align: top !important;

  /* override inline styles */
    border-color: #ccc !important;
    border-width: 3px !important;

  /* Word marks its own edges on cells inline (border-top-style:solid,
     border-right-style:solid, …). Combined with the border-width above, every
     one of those edges was drawing at full width — and because the table is
     border-collapse: separate, two adjacent cells' edges STACK rather than
     merge, so a line between two rows came out at 2 + 2 = 4px against a 2px
     outer frame. That is the thickness mismatch.

     Killing the style here makes every cell edge invisible by default; the
     rules below switch back on only the sides that are genuinely internal
     lines (row-to-row, column-to-column, header-to-body), each exactly once. */
    border-style: none !important;
    overflow-wrap: normal !important;
    word-break: normal !important;
    width: auto !important;
}

/* Word/CKEditor wraps every bit of cell text in its own <span style="color:...">
   (and sometimes <strong>/<em> inherit nothing extra) — color is inherited, so
   a span's own inline color always wins over the td/th rule above, regardless
   of !important there. Force every descendant flat black/transparent too, so
   every table renders in the same black-and-white theme no matter what colors
   the source Word doc used. */
.blog-content th *,
.blog-content td * {
  color: inherit !important;
  background-color: transparent !important;
}

/* CKEditor puts a <p> (and sometimes a list) inside every cell. Now that the
   whole file is !important, those pick up the 20px body-copy rule instead of
   the cell's own size, which blows the table's layout out. `inherit` sends them
   back to whatever the td/th is currently set to — deliberately not a hardcoded
   16px, so the mobile override at the bottom of this file keeps working and the
   two sizes can never drift apart. */
.blog-content th p,
.blog-content td p,
.blog-content th ol,
.blog-content td ol,
.blog-content th ul,
.blog-content td ul,
.blog-content th li,
.blog-content td li {
  font-size: inherit !important;
}

.blog-content th {
  font-weight: 700 !important;
}

/* Every horizontal line is drawn as the LOWER row's top edge — never as the
   upper row's bottom edge. That is what keeps a boundary to one line: with
   border-collapse: separate two adjacent edges stack instead of merging, so
   any rule that draws a bottom edge doubles up with the next row's top edge.

   The earlier `th { border-bottom }` was exactly that mistake. It looked like
   the single header-to-body divider only because that post kept its body rows
   in <tbody> as <td>. Other posts (e.g. snatchjobs) come out of Word with all
   14 cells as <th> and all 7 rows inside <thead>, so it fired on every row and
   drew a double line down the whole table. */
.blog-content tr+tr td,
.blog-content tr+tr th {
  border-top: 3px solid #000 !important;
  border-width: 3px !important;
}

/* `tr+tr` cannot reach across sections, so the first row after a section change
   would otherwise have no line above it. */
.blog-content thead + tbody > tr:first-child > td,
.blog-content thead + tbody > tr:first-child > th,
.blog-content tbody + tfoot > tr:first-child > td,
.blog-content tbody + tfoot > tr:first-child > th,
.blog-content thead + tfoot > tr:first-child > td,
.blog-content thead + tfoot > tr:first-child > th {
  border-top: 3px solid #000 !important;
  border-width: 3px !important;
}

.blog-content td+td,
.blog-content th+th,
.blog-content td+th,
.blog-content th+td {
  border-left: 3px solid #000 !important;
  border-width: 3px !important;
}

/* Gradient for whichever cell edges the rules above switched on. The ramp is
   diagonal on purpose: border-image slices the edge off each side of the image,
   so a 135deg ramp varies along the top/bottom edges AND down the left/right
   ones — a horizontal ramp would give gradient row lines but flat
   single-colour column lines.

   It has to be declared down here, in its own rule, rather than alongside the
   cell's other border longhands: the `border` shorthand resets border-image,
   and the build step merges adjacent longhands into exactly that shorthand —
   which silently dropped the gradient and left plain #000 lines. The
   `tr >` prefix keeps this from being merged back into that rule. */
.blog-content tr > th,
.blog-content tr > td {
  border-image: linear-gradient(135deg, var(--color-leaf), var(--color-teal), var(--color-sky)) 1 !important;
}

/* ── Rounded corners ──────────────────────────────────────────
   The table's outline is the gradient frame painted in its border box, which
   follows the 10px radius. The cells inside are square, and Word/CKEditor puts
   its own outer edges on them inline (e.g. border-right-style:solid on the last
   header cell) — that straight edge draws over the rounded corner, which is the
   line that appears to cut across the arc.

   So the frame owns the outline and the cells only draw the lines BETWEEN
   themselves: every outermost cell edge is dropped here. The rules above are
   untouched, since they only ever add a border where one cell follows another. */
.blog-content tr > *:first-child {
  border-left: 0 !important;
}

.blog-content tr > *:last-child {
  border-right: 0 !important;
}

.blog-content table > thead > tr:first-child > *,
.blog-content table > tbody:first-child > tr:first-child > * {
  border-top: 0 !important;
}

.blog-content table > tbody > tr:last-child > *,
.blog-content table > tfoot > tr:last-child > * {
  border-bottom: 0 !important;
}

/* The corner cells are also given the radius. Their white background would
   otherwise square off the inside of the arc — `overflow: hidden` on a <table>
   is not reliably honoured for this, which is why it isn't left to do the job.
   7px, not 10px: the inner edge of the 3px border sits that far inside it.

   The `thead:last-child` variants matter for tables that have no <tbody> at
   all — Word can emit every row inside <thead>, in which case the bottom
   corners of the table are thead's last row, not tbody's. */
.blog-content table > thead > tr:first-child > *:first-child,
.blog-content table > tbody:first-child > tr:first-child > *:first-child {
  border-top-left-radius: 7px !important;
}

.blog-content table > thead > tr:first-child > *:last-child,
.blog-content table > tbody:first-child > tr:first-child > *:last-child {
  border-top-right-radius: 7px !important;
}

.blog-content table > tbody:last-child > tr:last-child > *:first-child,
.blog-content table > thead:last-child > tr:last-child > *:first-child,
.blog-content table > tfoot:last-child > tr:last-child > *:first-child {
  border-bottom-left-radius: 7px !important;
}

.blog-content table > tbody:last-child > tr:last-child > *:last-child,
.blog-content table > thead:last-child > tr:last-child > *:last-child,
.blog-content table > tfoot:last-child > tr:last-child > *:last-child {
  border-bottom-right-radius: 7px !important;
}

/* ── Figure (wraps tables in CKEditor HTML) ───────────────── */

.blog-content figure {
  margin: 0px 0 !important;
  padding: 0 !important;
  overflow-x: auto !important;
  scrollbar-width: none !important;
  /* CKEditor's paste-from-Word carries Word's original table width over as an
     inline style (e.g. 624px, sized for a Word page column) — force it back to
     the content column's full width; overflow-x above still handles tables
     that are genuinely wider than the column (many columns). */
  width: 100% !important;
  max-width: 100% !important;
}

/* ── Images inside content ────────────────────────────────── */

.blog-content img {
  max-width: 100% !important;
  height: auto !important;
  border-radius: 24px !important;
  display: block !important;
  margin: 20px 0 !important;
}

/* ── Code ─────────────────────────────────────────────────── */

.blog-content code {
  font-family: "Fragment Mono", monospace !important;
  font-size: inherit !important;
  background-color: rgba(0, 0, 0, 0.1) !important;
  border-radius: 6px !important;
  padding: 0.1em 0.2em !important;
}

/* ── Blockquote ───────────────────────────────────────────── */

.blog-content blockquote {
  border-left: 3px solid var(--color-leaf-deep, #36b85f) !important;
  padding-left: 16px !important;
  margin: 20px 0 !important;
  font-style: italic !important;
  color: #40454d !important;
}

/* ── Responsive ───────────────────────────────────────────── */

@media (max-width: 1199px) and (min-width: 810px) {
  .blog-content h1 {
    font-size: 47px !important;
  }

  .blog-content h2 {
    font-size: 34px !important;
  }

  .blog-content h3 {
    font-size: 24px !important;
  }

  .blog-content h4 {
    font-size: 22px !important;
  }

  .blog-content h5 {
    font-size: 22px !important;
  }

  .blog-content h6 {
    font-size: 17px !important;
  }

  .blog-content p {
    font-size: 15px !important;
  }

  .blog-content ol,
  .blog-content ul {
    font-size: 15px !important;
  }
}

@media (max-width: 809px) {
  .blog-content h1 {
    font-size: 22px !important;
  }

  .blog-content h2 {
    font-size: 22px !important;
  }

  .blog-content h3 {
    font-size: 20px !important;
  }

  .blog-content h4 {
    font-size: 18px !important;
  }

  .blog-content h5 {
    font-size: 20px !important;
  }

  .blog-content h6 {
    font-size: 18px !important;
  }

  .blog-content p {
    font-size: 15px !important;
  }

  .blog-content ol,
  .blog-content ul {
    font-size: 15px !important;
  }

  .blog-content th,
  .blog-content td {
    font-size: 13px !important;
    padding: 8px !important;
  }
}