/*
   Documentation site, on top of site.css.

   Only what the documentation adds is defined here: the two-column shell, the
   navigation tree and the typography of a long read. The colours come from
   site.css, so the product and its documentation cannot drift apart, and the
   light/dark switch of the operating system is inherited with them.
*/

.docsBody {
    background: var(--bg);
    color: var(--text);
    margin: 0;
}

/* -- Header ------------------------------------------------------------- */

.docsHeader {
    align-items: center;
    background: var(--nav-bg);
    color: #fff;
    display: flex;
    gap: 16px;
    justify-content: space-between;
    padding: 10px 20px;
}

.docsBrand {
    align-items: center;
    color: #fff;
    display: flex;
    font-size: 1.05rem;
    gap: 10px;
    text-decoration: none;
}

.docsBrand strong {
    font-weight: 600;
}

/*
   min-height for WCAG 2.2 success criterion 2.5.8: measured 2026-08-16 this was 121 by 17.
   It is the only way back to the main site from the documentation, so it is a navigation
   control rather than a link inside a sentence, and the inline exception does not cover it.
*/
.docsHome {
    align-items: center;
    color: #fff;
    display: inline-flex;
    flex: none;
    font-size: 0.9rem;
    min-height: 24px;
    opacity: 0.85;
    text-decoration: none;
}

.docsHome:hover {
    opacity: 1;
    text-decoration: underline;
}

/* -- Search ------------------------------------------------------------- */

.docSearch {
    flex: 1 1 auto;
    margin: 0 auto;
    max-width: 460px;
    position: relative;
}

/*
   White on white until 2026-08-17. These colours were written for the dark bar
   the box used to sit in; the box then moved into the light panel beside the
   tree and kept them, so the field, its border and its placeholder were all
   invisible against the panel and the search read as a blank gap above
   "Overzicht". It now takes the colours of the surface it is actually on.
*/

.docSearch input {
    background: var(--bg);
    border: 1px solid var(--border);
    border-radius: 6px;
    color: var(--text);
    font: inherit;
    font-size: 0.92rem;
    padding: 6px 34px 6px 12px;
    width: 100%;
}

.docSearch input::placeholder {
    color: var(--muted);
}

.docSearch input:focus {
    background: var(--panel);
    border-color: var(--blue);
    color: var(--text);
    outline: 2px solid var(--blue);
    outline-offset: 1px;
}

.docSearch kbd {
    border: 1px solid var(--border);
    border-radius: 4px;
    color: var(--muted);
    font-size: 0.72rem;
    line-height: 1;
    padding: 2px 5px;
    pointer-events: none;
    position: absolute;
    right: 8px;
    top: 50%;
    transform: translateY(-50%);
}

.docSearch input:focus ~ kbd {
    display: none;
}

.docSearchPanel {
    background: var(--panel);
    border: 1px solid var(--border);
    border-radius: 8px;
    box-shadow: 0 8px 24px var(--shadow);
    left: 0;
    max-height: min(70vh, 560px);
    overflow-y: auto;
    position: absolute;
    right: 0;
    top: calc(100% + 6px);
    z-index: 50;
}

.docSearchHit,
.docSearchAll {
    border-bottom: 1px solid var(--border);
    color: var(--text);
    display: block;
    padding: 10px 14px;
    text-decoration: none;
}

.docSearchHit:last-of-type {
    border-bottom: none;
}

.docSearchHit:hover,
.docSearchHit.chosen,
.docSearchAll:hover,
.docSearchAll.chosen {
    background: var(--code-bg);
}

.docSearchHitTitle {
    color: var(--blue);
    display: block;
    font-weight: 600;
}

.docSearchHitText {
    color: var(--muted);
    display: block;
    font-size: 0.85rem;
    line-height: 1.45;
    margin-top: 2px;
}

.docSearchSection {
    background: var(--code-bg);
    border-radius: 3px;
    color: var(--muted);
    font-size: 0.72rem;
    margin-left: 6px;
    padding: 1px 6px;
    white-space: nowrap;
}

.docSearchHitTitle + .docSearchSection {
    margin-left: 0;
}

.docSearchAll {
    border-top: 1px solid var(--border);
    color: var(--blue);
    font-size: 0.85rem;
    text-align: center;
}

.docSearchEmpty {
    color: var(--muted);
    margin: 0;
    padding: 14px;
}

mark {
    background: var(--dv-hit);
    border-radius: 2px;
    color: inherit;
    padding: 0 1px;
}

/* -- Search results page ------------------------------------------------- */

.docSearchPageForm {
    display: flex;
    gap: 8px;
    margin-bottom: 16px;
    max-width: 74ch;
}

.docSearchPageForm input {
    background: var(--panel);
    border: 1px solid var(--border);
    border-radius: 6px;
    color: var(--text);
    flex: 1;
    font: inherit;
    padding: 8px 12px;
}

.docSearchPageForm button {
    background: var(--button-bg);
    border: none;
    border-radius: 6px;
    color: #fff;
    cursor: pointer;
    font: inherit;
    padding: 8px 18px;
}

.docSearchNote {
    color: var(--muted);
    font-size: 0.9rem;
    max-width: 74ch;
}

.docSearchResults {
    list-style: none;
    margin: 18px 0 0;
    max-width: 74ch;
    padding: 0;
}

.docSearchResults li {
    border-top: 1px solid var(--border);
    padding: 14px 0;
}

.docSearchResults li > a {
    color: var(--blue);
    font-size: 1.05rem;
    font-weight: 600;
    text-decoration: none;
}

.docSearchResults li > a:hover {
    text-decoration: underline;
}

.docSearchResults p {
    color: var(--muted);
    line-height: 1.6;
    margin: 4px 0 0;
}

@media (max-width: 700px) {
    .docSearch {
        margin: 0;
        max-width: none;
        width: 100%;
    }

    /* A keyboard shortcut advertised to a reader who has no keyboard. */
    .docSearch kbd {
        display: none;
    }
}

/* -- Shell -------------------------------------------------------------- */

/*
   The parts are placed by NAME rather than by their order in the markup, which
   is what lets a narrow screen read search, article, thumbs, tree while a wide
   one reads search over tree beside the article. The markup keeps the order a
   reader without a stylesheet needs, and the areas below decide the rest.
*/

.docsShell {
    display: grid;
    gap: 12px 32px;
    grid-template-areas:
        "search main rail"
        "nav    main rail";
    grid-template-columns: 280px minmax(0, 1fr) 200px;
    grid-template-rows: auto 1fr;
    margin: 0 auto;
    max-width: 1440px;
    padding: 24px 20px 64px;
}

.docsShell > .docSearch {
    grid-area: search;
    margin: 0;
    max-width: none;
}

.docsShell > .docsNav {
    grid-area: nav;
}

.docsShell > .docsMain {
    grid-area: main;
}

.docsShell > .page-rail {
    grid-area: rail;
}

/*
   Below 1180px the right rail goes first, so the shell is back to the tree and
   the article and the reader loses no width to a chapter list of one screen.
   The rail itself keeps its own rules from site.css: it drops under the
   article, its chapter list hides and only the thumbs remain.
*/

@media (max-width: 1180px) {
    .docsShell {
        grid-template-areas:
            "search main"
            "nav    main"
            "rail   rail";
        grid-template-columns: 280px minmax(0, 1fr);
        grid-template-rows: auto 1fr auto;
    }
}

/*
   One column, and the ORDER is the point of it. Until 2026-08-17 the tree came
   first here, because it comes first in the markup, so a telephone opened a
   topic on a full screen of navigation and the topic itself began below the
   fold. Now the search box stands at the top, where a reader who came to look
   something up needs it, the article follows straight away, and the tree drops
   to the foot of the page as the map it is.
*/

@media (max-width: 900px) {
    .docsShell {
        gap: 16px;
        grid-template-areas:
            "search"
            "main"
            "rail"
            "nav";
        grid-template-columns: minmax(0, 1fr);
        grid-template-rows: none;
        padding: 16px 12px 48px;
    }
}

/* -- Right rail --------------------------------------------------------- */

/*
   The rail is the marketing pages' rail, markup, classes and scripts alike,
   and everything it looks like is defined once in site.css. Only what this
   shell decides differs: this header does not stick, so the rail sits at the
   same height as the navigation tree instead of below a bar that is not there.
*/

.docsShell .page-rail .rail-sticky {
    top: 16px;
}

@media (max-width: 1180px) {
    .docsShell .page-rail .rail-sticky {
        position: static;
    }

    .docsShell .page-rail .toc {
        display: none;
    }
}

/* -- Navigation --------------------------------------------------------- */

.docsNav {
    align-self: start;
    background: var(--panel);
    border: 1px solid var(--border);
    border-radius: 8px;
    font-size: 0.93rem;
    max-height: calc(100vh - 120px);
    overflow-y: auto;
    padding: 12px;
    position: sticky;
    top: 16px;
}

/*
   Beside the article the tree scrolls within itself and stays in view; under
   the article it is the last thing on the page, so a box of its own with a
   scrollbar in it would be a second scroll area inside the one the reader is
   already using.
*/

@media (max-width: 900px) {
    .docsNav {
        max-height: none;
        overflow-y: visible;
        position: static;
    }
}

/* The heading belongs to that second position and to nothing else. */

.docsNavHeading {
    display: none;
    font-size: 0.75rem;
    letter-spacing: 0.04em;
    margin: 0 0 0.4rem;
    opacity: 0.7;
    text-transform: uppercase;
}

@media (max-width: 900px) {
    .docsNavHeading {
        display: block;
    }
}

.docsNav a {
    border-radius: 4px;
    color: var(--text);
    display: block;
    padding: 5px 8px;
    text-decoration: none;
}

.docsNav a:hover {
    background: var(--code-bg);
}

.docsNav a.current {
    background: var(--code-bg);
    color: var(--blue);
    font-weight: 600;
}

.docsNavTop {
    border-bottom: 1px solid var(--border);
    margin-bottom: 6px;
    padding-bottom: 8px !important;
}

.docsNavSection > summary {
    cursor: pointer;
    list-style: none;
}

.docsNavSection > summary::-webkit-details-marker {
    display: none;
}

.docsNavSection > summary::before {
    color: var(--muted);
    content: "\25B8";
    display: inline-block;
    font-size: 0.8em;
    transition: transform 0.12s ease;
    width: 1em;
}

.docsNavSection[open] > summary::before {
    transform: rotate(90deg);
}

.docsNavSection > summary > a {
    display: inline-block;
    font-weight: 600;
    width: calc(100% - 1.4em);
}

.docsNavSection > .docsNavItem,
.docsNavSection > .docsNavSection {
    margin-left: 14px;
}

/* -- Body --------------------------------------------------------------- */

/*
   Two lines here keep a topic inside a telephone, and both were established by
   measurement on 2026-08-17.

   The overflow rule breaks a word longer than the line rather than letting it
   push the article open. The documentation is full of such words: addresses,
   tool names, setting keys, ECLI numbers, and titles like "OpenBesluitvorming",
   which at heading size is 8px wider than a 320px screen on its own. None of
   them holds a space or a hyphen, so a browser has nowhere to break them
   without being told. "break-word" leaves ordinary words alone and only breaks
   the one that has nowhere left to go. It sits on the article rather than on
   the text of the article, because the title, the breadcrumb and the date line
   are outside .docBody and each of them can carry such a word.

   The margin is the load-bearing line here, however odd that looks. site.css
   says "main { margin: 0 auto }" for every page of the site, and an automatic
   margin on a grid item takes the item OUT of the stretch its column gives it:
   the browser then sizes it to its own content and lets it hang over the edge
   of the page. Measured on 2026-08-17 on a 375px screen: the column was 335px
   wide, the article 663px, and the whole page scrolled sideways, which is what
   made every line of every topic run past the right edge of a telephone. The
   overflow rules further down handle content that cannot be made narrower; this
   one makes the article itself obey the column.
*/

.docsMain {
    background: var(--panel);
    border: 1px solid var(--border);
    border-radius: 8px;
    margin: 0;
    min-width: 0;
    overflow-wrap: break-word;
    padding: 28px 36px 40px;
}

/*
   72px of padding out of a 375px screen is a fifth of the line gone before the
   first word. Narrow screens get the space back and read at roughly 40 to 45
   characters a line instead of 30.
*/

@media (max-width: 900px) {
    .docsMain {
        padding: 20px 16px 32px;
    }

}

.docTrail {
    color: var(--muted);
    font-size: 0.85rem;
    margin-bottom: 8px;
}

.docTrail a {
    color: var(--muted);
}

.docTrailSeparator {
    padding: 0 6px;
}

.docsMain h1 {
    font-size: 1.9rem;
    line-height: 1.2;
    margin: 0 0 20px;
}

/*
   The title comes down with the padding on a narrow screen. At 1,9rem a
   one-word title of the length these topics carry ("OpenBesluitvorming",
   "Officiële Bekendmakingen") fills the whole width and then breaks in the
   middle of itself; at 1,55rem it fits and stays one word. This block stands
   AFTER the rule it overrides on purpose: the two have the same weight, so the
   order in the file is what decides, and written above it the media query would
   be read and then quietly discarded.
*/

@media (max-width: 900px) {
    .docsMain h1 {
        font-size: 1.55rem;
    }
}

/*
    The day the topic last changed, directly under the title. Pulled up against
    the heading it belongs to, so it reads as part of the title block rather
    than as the first sentence of the text.
*/
.docChanged {
    color: var(--muted);
    font-size: 0.85rem;
    margin: -14px 0 22px;
}

.docBody {
    font-size: 1rem;
    line-height: 1.65;
    max-width: 74ch;
}

/*
   An address in code is the standing example, and it needs the stronger value:
   "break-word" first tries to put the whole token on a line of its own, which
   on a telephone is still too wide, where "anywhere" breaks it where it must.
*/

.docBody code {
    overflow-wrap: anywhere;
}

/*
   Not inside a table, though. A cell is already narrow, so breaking an address
   there cuts it into three pieces of four characters and the reader is looking
   at a column of fragments rather than at an address they could type in. The
   table has somewhere else to go: it scrolls sideways in its own box, which
   keeps the address whole and costs a gesture the reader is used to making.
*/

.docBody td code,
.docBody th code {
    overflow-wrap: normal;
}

.docBody h2 {
    border-top: 1px solid var(--border);
    font-size: 1.3rem;
    margin: 32px 0 10px;
    padding-top: 20px;
}

.docBody h3 {
    font-size: 1.1rem;
    margin: 24px 0 8px;
}

.docBody p {
    margin: 0 0 14px;
}

.docBody ul,
.docBody ol {
    margin: 0 0 14px;
    padding-left: 22px;
}

.docBody li {
    margin-bottom: 4px;
}

.docBody code {
    background: var(--code-bg);
    border-radius: 3px;
    font-size: 0.9em;
    padding: 1px 5px;
}

.docBody pre {
    background: var(--pre-soft-bg);
    border: 1px solid var(--border);
    border-radius: 6px;
    overflow-x: auto;
    padding: 12px 14px;
}

.docBody pre code {
    background: none;
    padding: 0;
}

/*
   A table is the one thing on these pages that has a floor: three columns of
   addresses and figures cannot be folded into 340px, and shrinking the type
   until they fit trades one unreadable page for another. So the table gets a
   box of its own that scrolls sideways, and the page does not. The box only
   scrolls when the table really does not fit; on a wide screen nothing about it
   is visible. It is focusable because a scroll area that only a mouse or a
   finger can move is unreachable for a reader on a keyboard.
*/

.docTable {
    margin: 0 0 18px;
    max-width: 100%;
    overflow-x: auto;
}

.docTable:focus-visible {
    outline: 2px solid var(--blue);
    outline-offset: 2px;
}

.docBody table {
    border-collapse: collapse;
    margin: 0 0 18px;
    width: 100%;
}

.docTable > table {
    margin: 0;
}

.docBody th,
.docBody td {
    border: 1px solid var(--border);
    padding: 6px 10px;
    text-align: left;
    vertical-align: top;
}

.docBody th {
    background: var(--code-bg);
}

.docBody img {
    height: auto;
    max-width: 100%;
}

/*
   A diagram is scaled to the width of the column by mermaid itself, see the
   configuration in _DocumentationLayout. The scrolling here is the safety net
   under that: a diagram type mermaid does not scale stays inside its own block
   instead of pushing the article open, which on a telephone is the difference
   between one awkward diagram and a page whose every line runs off the screen.
*/

.docBody pre.mermaid {
    background: none;
    border: none;
    max-width: none;
    overflow-x: auto;
    padding: 8px 0;
    text-align: center;
    width: 100%;
}

/* -- The product grid of the landing page -------------------------------- */

.productGrid {
    display: grid;
    gap: 16px;
    grid-template-columns: repeat(auto-fill, minmax(230px, 1fr));
    margin: 24px 0;
}

.productGrid a {
    align-items: center;
    background: var(--bg);
    border: 1px solid var(--border);
    border-radius: 8px;
    color: var(--text);
    display: flex;
    font-weight: 600;
    min-height: 64px;
    padding: 14px 16px;
    text-decoration: none;
}

.productGrid a:hover {
    border-color: var(--blue);
}

.productGrid a::before {
    background: url(/img/logo/besluitbron-icon.svg) no-repeat center center;
    background-size: contain;
    content: "";
    display: inline-block;
    height: 32px;
    margin-right: 12px;
    width: 32px;
}

/* -- Footer -------------------------------------------------------------- */

.docsFooter {
    border-top: 1px solid var(--border);
    color: var(--muted);
    display: flex;
    flex-wrap: wrap;
    font-size: 0.85rem;
    gap: 8px 24px;
    justify-content: space-between;
    margin: 0 auto;
    max-width: 1240px;
    padding: 16px 20px 32px;
}

/* The site navigation in the documentation header. Same links as the marketing header, so the
   documentation is a section of the site and not a mode you have to leave. */
.docsSiteNav { display: flex; gap: 1rem; align-items: center; font-size: .9375rem; }
.docsSiteNav a { text-decoration: none; opacity: .8; white-space: nowrap; }
.docsSiteNav a:hover { opacity: 1; text-decoration: underline; }
.docsSiteNavCurrent { font-weight: 500; opacity: 1; }

/* The folder marker was a small glyph at body size and the indentation was a few pixels, so a
   reader could not see which topic sat inside which folder. Both are now unmistakable: a marker
   at 1.1rem that rotates when the folder opens, and a rule down the left of every nested level so
   the depth is drawn rather than implied. */
.docsNav details > summary { list-style: none; cursor: pointer; display: flex; align-items: center; gap: .45rem; padding: .25rem 0; font-weight: 500; }
.docsNav details > summary::-webkit-details-marker { display: none; }
.docsNav details > summary::before { content: "\25B8"; font-size: 1.1rem; line-height: 1; display: inline-block; width: 1rem; text-align: center; transition: transform .12s ease; }
.docsNav details[open] > summary::before { transform: rotate(90deg); }
.docsNav details > a, .docsNav details > .docsNavItem { display: block; margin-left: .95rem; padding: .22rem 0 .22rem .8rem; border-left: 2px solid rgba(128,128,128,.35); }
.docsNav details > a:hover, .docsNav details > .docsNavItem:hover { border-left-color: rgba(128,128,128,.7); }
.docsNav details > a.current, .docsNav details > .docsNavItem.current { border-left-color: currentColor; font-weight: 500; }
@media (prefers-reduced-motion: reduce) { .docsNav details > summary::before { transition: none; } }

/* The chapter list gets a heading, and it disappears with the list on a topic without chapters
   rather than standing over nothing. */
.railHeading { font-size: .75rem; letter-spacing: .04em; text-transform: uppercase; opacity: .7; margin: 0 0 .4rem 0; }
.page-rail .toc:empty { display: none; }
.page-rail .toc:empty + .railHeading, .railHeading:has(+ .toc:empty) { display: none; }

/* The search sits over the left column, so it is where the reader is already looking for a topic
   instead of in a bar that is now shared with the rest of the site. On a narrow screen the same
   box is the first thing on the page, which is why it is a child of the shell and not of the tree
   it used to sit in. */
.docsShell .docSearch { position: relative; display: block; }
.docsShell .docSearch input { width: 100%; box-sizing: border-box; }
.docsShell .docSearch kbd { position: absolute; right: .5rem; top: 50%; transform: translateY(-50%); }
.docsShell .docSearchPanel { left: 0; right: 0; }

/* The current topic in the navigation was link blue on the panel it sits on: 3,83:1 measured in
   the dark scheme, under the 4,5:1 that AA asks and exactly what an audit flags. It now takes the
   body text colour, which the palette already guarantees against that background, and keeps its
   emphasis from the weight and the left border instead of from a hue. Reached for the colour the
   site already has rather than inventing a lighter blue: one more hand-picked value is one more
   thing to re-check on the next palette change. */
.docsNav a.docsNavItem.current,
.docsNav details > a.docsNavItem.current,
.docsNav a.docsNavTop.current { color: var(--text); font-weight: 500; }

/* Tap targets. Lighthouse measured target-size at 0 on the documentation pages: the navigation
   items sat at roughly 24px high, under the 24x24 minimum, and the chapter links in the right rail
   with them. Raising the vertical padding costs a little density in a sidebar that has room, and it
   is the difference between a list that can be used with a thumb and one that cannot. */
.docsNav a, .docsNav details > summary, .page-rail .toc a { min-height: 32px; display: flex; align-items: center; width: 100%; box-sizing: border-box; }
.docsNav a, .page-rail .toc a { padding-top: .4rem; padding-bottom: .4rem; }
.docsNav details > summary { padding-top: .45rem; padding-bottom: .45rem; }

/* The chevron is its own tap target beside the link, not around it. Laid out on one row with the
   link that follows it, which is what keeps the tree looking like a tree now that the two are
   siblings in the markup. */
.docsNav details.docsNavSection > summary { display: flex; align-items: center; gap: 0; padding: 0; pointer-events: none; }
.docsNav details.docsNavSection > summary::before { content: none; }
.docsNavChevron { pointer-events: auto; cursor: pointer; width: 32px; min-width: 32px; height: 32px; display: inline-flex; align-items: center; justify-content: center; }
.docsNavChevron::before { content: "\25B8"; font-size: 1.1rem; line-height: 1; display: inline-block; transition: transform .12s ease; }
.docsNav details.docsNavSection[open] > summary .docsNavChevron::before { transform: rotate(90deg); }
.docsNavSectionLink { pointer-events: auto; display: flex; align-items: center; min-height: 32px; flex: 1; font-weight: 500; text-decoration: none; }
@media (prefers-reduced-motion: reduce) { .docsNavChevron::before { transition: none; } }

/*
    The notice a machine-translated page carries. Deliberately quiet rather than a warning
    banner: it is a statement of provenance that has to be readable and findable, not an alarm,
    and a page that shouted this at every reader would train them to stop seeing it. It sits
    above the body, because a reader has to meet it before the text and not after.
*/
.docNotice {
    margin: 0 0 1.5rem;
    padding: 0.7rem 0.9rem;
    border-inline-start: 3px solid var(--muted, #7a7a7a);
    background: color-mix(in srgb, currentColor 4%, transparent);
    font-size: 0.9rem;
}

.docNotice p {
    margin: 0;
}