/* ══════════════════════════════════════════════════════════════════════════
   Role-to-role visibility matrix
   ══════════════════════════════════════════════════════════════════════════

   A mock of the app's Cross Role Visibility screen: a rail of roles on the
   left, and for whichever role is selected, a row per other role with two
   permissions — whether their updates are visible, and whether this role can
   manage their entries.

   Built as markup rather than a screenshot, for the reason every mock on these
   pages is: it is almost entirely small type, which is what raster and
   generative output handle worst. As markup it stays sharp at any pixel
   density, uses the real brand font and the real teal, is edited by changing a
   word, and is readable to search engines and screen readers.

   Five departures from the real screen, each because a product screenshot and
   a marketing graphic are answering different questions:

     1. No tab bar. The app has "Cross Role Visibility | Pages"; a second tab
        the reader cannot click raises a question the page does not answer.
        The active tab's label becomes the panel title instead.
     2. Nothing is cut off. The real screen scrolls, so its last row is sliced
        in half. In a static graphic a sliced row reads as broken rather than
        as scrollable, so the set shown is complete.
     3. The rail and the table list the same roles. In the app they are
        different lengths, which makes the relationship between the two panes
        something you have to work out; here the rail is visibly the table's
        index.
     4. Six roles, not twenty. Enough to show a mixed pattern of allowed and
        denied, few enough to read at a glance.
     5. The selected role's own row is locked on rather than editable — which
        is the real rule (a role always sees itself) shown rather than stated.

   Scale. A mock has to read as a screen seen at a distance, not as a control
   panel the visitor could click, so everything is set from --rv-pad and the
   small type sizes below rather than from the page's body scale. Retune the
   whole thing by changing --rv-pad and the font sizes together.

   Every selector is scoped to .static-page, so this file is safe to load on
   any page that declares it in deps.json.
   ══════════════════════════════════════════════════════════════════════════ */

/* The wrapper exists only to be the query container: an element cannot size
   itself against its own width, so the switch below has to be asked of the
   parent. Everything visible is on .kb-roles. */
.static-page .kb-roles-wrap {
    container-type: inline-size;
}

.static-page .kb-roles {
    --rv-pad: 1.2rem;
    --rv-radius: 16px;
    --rv-line: #EFF4F3;
    display: grid;
    /* The rail is fixed and the table takes the rest: the rail holds names of
       a known length, while the table has two value columns to fit and should
       get every pixel that is left. */
    /* 11rem holds "Marketing Director" on one line — at 10.5rem it was short
       by a single pixel and wrapped. The two long specialist names still wrap
       to two lines, which is expected and is what the real screen does; a rail
       wide enough for those would be a third of the component. */
    grid-template-columns: 11rem 1fr;
    max-width: 39rem;
    margin-inline: auto;
    background: #ffffff;
    border: 1px solid #E9EFEE;
    border-radius: var(--rv-radius);
    overflow: hidden;
    /* Two shadows: a tight one to hold the edge against a white section, and a
       wide diffuse one for lift. One shadow doing both jobs is either too hard
       at the edge or too weak underneath. */
    box-shadow:
        0 1px 2px rgba(21, 41, 39, 0.05),
        0 18px 40px -26px rgba(21, 41, 39, 0.45);
    /* Real interfaces are dense. Left to inherit, the page's body line-height
       nearly double-spaces 11px UI text and turns a screen into a sparse form. */
    line-height: 1.35;
    letter-spacing: -0.005em;
}

/* ── Rail ────────────────────────────────────────────────────────────────── */

.static-page .kb-roles__rail {
    padding: var(--rv-pad) 0.85rem;
    background: #FBFDFC;
    border-right: 1px solid var(--rv-line);
}
.static-page .kb-roles__rail-title {
    display: block;
    margin: 0 0 0.6rem 0.5rem;
    font-size: 0.7rem;
    font-weight: 700;
    letter-spacing: 0.08em;
    text-transform: uppercase;
    color: var(--sp-ink-faint);
}
.static-page .kb-roles__list {
    list-style: none;
    margin: 0;
    padding: 0;
}
.static-page .kb-roles__list li {
    margin: 0;
    padding: 0.46rem 0.55rem;
    border-radius: 8px;
    font-size: 0.84rem;
    color: var(--sp-ink-soft);
}
/* The selected role is the one the table is describing, so it carries the
   teal — the eye can follow the name from the rail to the chip in the panel
   header and know the two are the same thing. It is the only teal in the rail
   for exactly that reason. */
.static-page .kb-roles__list li.is-selected {
    background: var(--sp-brand-teal-tint);
    font-weight: 700;
    color: var(--sp-brand-teal);
}

/* ── Panel ───────────────────────────────────────────────────────────────── */

.static-page .kb-roles__panel {
    padding: var(--rv-pad);
    min-width: 0;
}
.static-page .kb-roles__head {
    display: flex;
    align-items: center;
    justify-content: space-between;
    gap: 0.6rem;
    margin-bottom: 0.85rem;
}
.static-page .kb-roles__title {
    font-size: 0.94rem;
    font-weight: 700;
    letter-spacing: -0.015em;
    color: var(--sp-ink);
}
/* Names the role being edited, so the panel is visibly tied to the highlighted
   row in the rail. */
.static-page .kb-roles__role {
    display: inline-flex;
    align-items: center;
    gap: 0.28rem;
    flex: none;
    padding: 0.26rem 0.6rem;
    border: 1px solid var(--sp-brand-teal-soft);
    border-radius: 999px;
    background: var(--sp-brand-teal-tint);
    font-size: 0.7rem;
    font-weight: 700;
    color: var(--sp-brand-teal);
    white-space: nowrap;
}
.static-page .kb-roles__role i {
    font-size: 0.92rem;
}

/* ── Matrix ──────────────────────────────────────────────────────────────── */

/* One grid for every row so the two value columns line up without each row
   having to agree about widths. The value columns are sized to their headings,
   which are longer than the controls they sit above. */
.static-page .kb-roles__row {
    display: grid;
    grid-template-columns: 1fr 6.4rem 6.4rem;
    align-items: center;
    gap: 0.5rem;
    padding: 0.5rem 0;
}
.static-page .kb-roles__row + .kb-roles__row {
    border-top: 1px solid var(--rv-line);
}
/* Bold sentence case, not tracked uppercase: the real settings screen labels
   these columns as plain bold words, and at this size an all-caps micro-label
   would be the only thing in the mock speaking a different language. */
.static-page .kb-roles__row--head {
    padding-top: 0;
    padding-bottom: 0.58rem;
    border-bottom: 1px solid #E3EBE9;
    font-size: 0.76rem;
    font-weight: 700;
    color: var(--sp-ink);
}
/* Wraps rather than truncating. The panel is narrowest in a two-column
   section at ~1024px and again on a phone, and at both the longest role names
   run past the column. An ellipsis is the wrong answer here specifically: this
   is a graphic about which role sees which, so a clipped role name removes the
   one fact each row exists to carry. Two lines costs a little height in two of
   six rows; the checkbox stays centred against whatever the name turns out to
   be, so nothing else has to know. */
.static-page .kb-roles__name {
    min-width: 0;
    font-size: 0.84rem;
    color: var(--sp-ink-soft);
}
.static-page .kb-roles__row--head .kb-roles__name {
    font-size: 0.76rem;
    color: var(--sp-ink);
}
/* The selected role's own row. Named rather than left to be inferred from the
   checkbox state, because "always" is the point. */
.static-page .kb-roles__row--self .kb-roles__name {
    font-weight: 700;
    color: var(--sp-ink);
}
.static-page .kb-roles__self-tag {
    margin-left: 0.4rem;
    font-size: 0.66rem;
    font-weight: 600;
    letter-spacing: 0.04em;
    text-transform: uppercase;
    color: var(--sp-ink-faint);
}

/* ── Checkbox ────────────────────────────────────────────────────────────── */

/* Three states, and the difference between the last two is the whole reason
   this graphic is worth drawing:
     off      — an empty box, editable
     is-on    — solid teal, editable, deliberately granted
     is-locked— teal tint with a teal tick, NOT editable: the role's own row,
                on because it cannot be otherwise.
   A locked box that looked identical to a granted one would say the admin
   chose something they cannot choose. */
.static-page .kb-roles__box {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    width: 1.1rem;
    height: 1.1rem;
    border: 1.5px solid #C6D5D2;
    border-radius: 5px;
    background: #ffffff;
    font-size: 0.7rem;
    line-height: 1;
    color: transparent;
}
.static-page .kb-roles__box.is-on {
    background: var(--sp-brand-teal);
    border-color: var(--sp-brand-teal);
    color: #ffffff;
}
.static-page .kb-roles__box.is-locked {
    background: var(--sp-brand-teal-tint);
    border-color: var(--sp-brand-teal-soft);
    color: var(--sp-brand-teal);
}

/* ── Footnote ────────────────────────────────────────────────────────────── */

/* The rule the matrix is an instance of. Without it a reader can see that some
   boxes are on and some are off but not what follows from that. */
.static-page .kb-roles__note {
    grid-column: 1 / -1;
    padding: 0.7rem var(--rv-pad);
    border-top: 1px solid var(--rv-line);
    background: #FBFDFC;
    font-size: 0.72rem;
    line-height: 1.5;
    color: var(--sp-ink-muted);
}
.static-page .kb-roles__note i {
    margin-right: 0.28rem;
    color: var(--sp-brand-teal);
}

/* The rail and the matrix cannot always share a row: below about 600px the
   rail would take a third of the width to show six names and leave the two
   value columns fighting over the rest. The rail becomes a horizontal strip of
   chips above the matrix, which keeps it as the table's index while costing
   one line.

   620px rather than a round number, because it is derived: with the sidebar
   present the name column is the component's width less 437px of rail, padding
   and value columns, and the longest role name needs 181px of that. So the
   sidebar earns its place only above ~618px; below it the rail is taking width
   the names need more.

   This asks the container, not the viewport, and the distinction is the whole
   point of the rule. The graphic's width is set by whatever column it is
   dropped into, not by the screen: in this page's two-column section it gets
   626px at 1200px wide but only 524px at 1024px, while in a full-width section
   at 768px it gets the full 624px. Keyed to the viewport the switch would fire
   at the wrong moments in both directions — sidebar where there is no room,
   chips where there is plenty — and the behaviour would not even be monotonic
   as the window narrows. Keyed to the container it is simply "switch when the
   rail stops fitting", which is true wherever the component is used. */
@container (max-width: 620px) {
    .static-page .kb-roles {
        grid-template-columns: 1fr;
    }
    .static-page .kb-roles__rail {
        padding: var(--rv-pad) var(--rv-pad) 0.9rem;
        border-right: 0;
        border-bottom: 1px solid var(--rv-line);
    }
    .static-page .kb-roles__rail-title {
        margin-left: 0;
    }
    .static-page .kb-roles__list {
        display: flex;
        flex-wrap: wrap;
        gap: 0.35rem;
    }
    .static-page .kb-roles__list li {
        padding: 0.28rem 0.6rem;
        border: 1px solid var(--rv-line);
        border-radius: 999px;
        background: #ffffff;
        font-size: 0.76rem;
    }
    .static-page .kb-roles__list li.is-selected {
        border-color: var(--sp-brand-teal-soft);
        background: var(--sp-brand-teal-tint);
    }
}

/* A second step for genuinely narrow columns — a phone, or a third-width card.
   The value columns shrink past what their headings need on one line, so
   "Updates visible" and "Manage entries" wrap to two. That is the deliberate
   trade rather than an oversight: a heading is set once at the top of the
   table, where two lines cost nothing, and the width it gives up goes to the
   role names, which repeat on all six rows and are what the reader is actually
   scanning. Sizing the columns to keep the headings on one line here would
   push every name to three lines instead.

   The controls do not shrink — a checkbox is already the smallest thing in the
   component that still has to read as a checkbox. */
@container (max-width: 420px) {
    .static-page .kb-roles__row {
        grid-template-columns: 1fr 4.2rem 4.2rem;
        gap: 0.4rem;
    }
    .static-page .kb-roles__row--head,
    .static-page .kb-roles__row--head .kb-roles__name {
        font-size: 0.68rem;
    }
    .static-page .kb-roles__name {
        font-size: 0.78rem;
    }
}