/* Overrides for sphinx_rtd_theme's own theme.css -- see doc/conf.py's
 * html_css_files. Two fixed problems, both from the theme's own defaults:
 *
 * 1. ".wy-nav-content { max-width: 800px }" caps the reading column at
 *    800px regardless of viewport width, leaving most of a normal monitor
 *    empty. Widened here -- still centered by the theme's own "margin:
 *    auto", just no longer clamped.
 *
 * 2. ".rst-content code, .rst-content tt { white-space: nowrap }" is fine
 *    for a short inline code span in a paragraph, but inside a table cell
 *    (this codebase's doc/*.md tables regularly put a code span in a
 *    column, e.g. doc/configuration/denver-toml.md's shell-variable table)
 *    it stops that cell from wrapping at all -- the whole table pushes
 *    wider than its container instead of breaking the line, i.e. exactly
 *    the "tables don't linebreak" symptom. Restoring normal wrapping only
 *    inside table cells (not globally -- an inline code span mid-sentence
 *    still shouldn't break mid-token) fixes that without touching how code
 *    spans look anywhere else.
 */

.wy-nav-content {
  max-width: none;
}

.rst-content table.docutils code,
.rst-content table.docutils tt {
  white-space: normal;
  overflow-wrap: break-word;
}

/* The cells themselves: docutils/RTD tables are otherwise auto-sized to
 * their widest line, which fights the code-span fix above -- a cell whose
 * only wrappable content is that code span still won't wrap unless the
 * cell's own text is allowed to break too. */
.rst-content table.docutils td,
.rst-content table.docutils th {
  white-space: normal;
}

/* 3. Blockquotes (GFM '>' cites, e.g. doc/quickstart/30-minutes.md's "The
 *    use case") render with the theme's default of just a left margin and
 *    no visual boundary -- easy to mistake for a regular indented
 *    paragraph. A full box makes clear where a quoted passage starts and
 *    ends, without needing anything beyond plain '>' markup in the source
 *    (so the same .md still renders sensibly on GitHub). */
.rst-content blockquote {
  border: 1px solid #e1e4e5;
  border-left: 4px solid #999;
  border-radius: 4px;
  background: #fafafa;
  padding: 12px 18px;
}

/* The theme's own admonitions (.note, .tip, ...) strip the last paragraph's
 * bottom margin (see theme.css's "p:last-child{margin-bottom:0}") so the box
 * ends flush with its own padding. A plain blockquote isn't one of those, so
 * its last paragraph kept that margin on top of the padding above -- a gap
 * at the bottom of every box that the top never had. Docutils always wraps
 * a blockquote's content in its own <div> ("<blockquote><div><p>...",
 * confirmed in the built HTML), so the real last paragraph is a *descendant*
 * of blockquote, not a direct child -- a plain descendant selector (no '>')
 * is what actually reaches it. */
.rst-content blockquote :last-child {
  margin-bottom: 0;
}

/* 4. GitHub's blockquote-based alerts ('> [!NOTE]', '> [!TIP]', ...) --
 * GitHub renders these natively; Sphinx doesn't know about them at all, so
 * without help they'd just show as a plain blockquote (styled by #3 above)
 * with the literal "[!NOTE]" text sitting in the first line. custom.js
 * strips that marker and adds the 'alert'/'alert-<type>' classes below,
 * mirroring GitHub's own five colors and adding a bold type label in front
 * of where the marker text was. */
.rst-content blockquote.alert {
  border-left-width: 4px;
}

.rst-content blockquote.alert-note {
  border-color: #0969da;
  background: #ddf4ff;
}

.rst-content blockquote.alert-tip {
  border-color: #1a7f37;
  background: #dafbe1;
}

.rst-content blockquote.alert-important {
  border-color: #8250df;
  background: #fbefff;
}

.rst-content blockquote.alert-warning {
  border-color: #9a6700;
  background: #fff8c5;
}

.rst-content blockquote.alert-caution {
  border-color: #cf222e;
  background: #ffebe9;
}

.rst-content blockquote.alert .alert-title {
  font-weight: 700;
  text-transform: capitalize;
}

/* 5. The sidebar version line (doc/_templates/layout.html). sphinx_rtd_theme
 *    3.x dropped both the markup and the styling its older versions had for
 *    this, so both live here now.
 *
 *    The theme's own sidebartitle block ends with the search box, so the
 *    template can only append after it -- these two rules put the line back
 *    between the title and the box, where the theme used to render it,
 *    without the template having to restate the whole block (and drift from
 *    it on the next theme upgrade). Everything else in the header keeps its
 *    default order of 0, i.e. stays in source order ahead of these two. */
.wy-side-nav-search {
  display: flex;
  flex-direction: column;
}

.wy-side-nav-search > div.version {
  order: 1;
  margin-top: -0.4045em;
  margin-bottom: 0.809em;
  font-weight: 400;
  color: hsla(0, 0%, 100%, 0.4);
}

.wy-side-nav-search > [role="search"] {
  order: 2;
}

/* The link is the version string itself -- it should read as that line, not
 * as a blue link on a blue header; the underline on hover is what signals
 * it's clickable. */
.wy-side-nav-search > div.version a,
.wy-side-nav-search > div.version a:visited {
  color: inherit;
  text-decoration: none;
}

.wy-side-nav-search > div.version a:hover {
  color: #fcfcfc;
  text-decoration: underline;
}