/* Custom admin styles */

/* Navbar: slightly darker gray than Bootstrap bg-light */
.admin-navbar {
  background-color: #e0e0e0 !important; /* more gray */
}

/* Main content centered container */
.main-content-wrapper {
  background: #ffffff; /* keep page sides white */
}

.main-container {
  max-width: 1424px;
  margin: 0 auto;
  background-color: #f5f5f5; /* slightly gray background for content area */
  padding: 12px;
}

/* Status badges for project status */
.status-badge {
  display: inline-block;
  padding: 2px 10px;
  border-radius: 999px;
  font-size: 12px;
  line-height: 1.4;
  color: #fff;
  font-weight: 600;
}
.status-published { background-color: #28a745; }
.status-draft { background-color: #fd7e14; }

/* Materials tree: collapsible folder toggles */
.material-folder-toggle {
  cursor: pointer;
  user-select: none;
}
.material-folder-toggle:hover .material-folder-caret {
  color: #ec3013;
}
.material-folder-caret {
  display: inline-block;
  width: 0.9em;
  color: #6c757d;
  font-size: 0.85em;
}

/* AI Teaching Assistant: flash the answer card when a reply arrives.

   Green, not the site's blue: blue is already the colour of every link and
   button inside this card, so a blue tint reads as chrome rather than as
   change. Two slow cycles at ~0.9 Hz, deliberately nowhere near the 3 Hz
   threshold at which flashing content becomes a seizure risk.

   Selector is .card.assistant-answer-pulse, not the bare class: Bootstrap's
   .card sets background-color, and equal specificity would leave the outcome
   to stylesheet order. The extra class wins outright. */
@keyframes assistantAnswerPulse {
  0%   { background-color: rgba(25, 135, 84, 0.16); }
  50%  { background-color: rgba(25, 135, 84, 0.00); }
  100% { background-color: rgba(25, 135, 84, 0.16); }
}
.card.assistant-answer-pulse {
  background-color: rgba(25, 135, 84, 0.16);
  animation: assistantAnswerPulse 1.1s ease-in-out 2;
}
@media (prefers-reduced-motion: reduce) {
  /* No flashing, but keep the static tint: the JS removes the class on a timer,
     so these visitors still get a visible cue rather than nothing at all. */
  .card.assistant-answer-pulse { animation: none; }
}

/* Admin dashboard: the four statistics tiles that share one card.

   Separators are drawn here rather than with per-tile border utilities because
   WHICH edge needs a line changes at the breakpoint: stacked below 768px every
   tile but the first needs a line above it, while at two columns the second
   tile of a row must not repeat it and the left column gains a vertical rule.
   768px is not a free choice — it is where .row-cols-md-2 folds. */
.stat-tiles > .stat-tile + .stat-tile {
  border-top: 1px solid var(--bs-border-color);
}
@media (min-width: 768px) {
  .stat-tiles > .stat-tile:nth-child(2) {
    border-top: 0;
  }
  /* :not(:last-child) so an ODD number of tiles does not leave the last one
     drawing a vertical rule against empty space. */
  .stat-tiles > .stat-tile:nth-child(odd):not(:last-child) {
    border-right: 1px solid var(--bs-border-color);
  }
}
/* The whole tile is a link (.stretched-link), so it needs to say so on hover. */
.stat-tiles > .stat-tile:hover {
  background-color: var(--bs-tertiary-bg);
}
/* …but not over the figures. .stretched-link::after covers the tile at z-index 1,
   which swallows text selection: mousedown and mouseup on a number both land on
   the link, so dragging to copy "9,836" navigates to the report instead. This is
   the only place those figures appear, and they were plain selectable text before
   the tiles existed, so lifting them back above the overlay keeps both — a
   tile-sized click target, and numbers you can still select. A click directly on
   a figure now does nothing, which is the right answer for clicking text. */
.stat-tiles > .stat-tile h5 {
  position: relative;
  z-index: 2;
}

/* Text links: NORMAL font color with a FINE RED UNDERLINE, red text only on
   hover. Red link TEXT has now been tried and rejected TWICE — task 14's
   first pass and the 2026-07-29 global red pass both drew the same client
   verdict ("sieht aus wie ein defekter Link") — so do not reintroduce it;
   red stays on buttons, pagination boxes, icons and controls. Bare links
   outside this rule get their rest color from the --bs-link-* redefinition
   below (body color at rest, red on hover). The :not() chain excludes
   everything that carries its own look: buttons, badges, nav pills,
   dropdowns, pagination, and the card-as-link patterns (.text-reset /
   .text-decoration-none / .stretched-link). */
.page-content a:not(.btn):not(.badge):not(.nav-link):not(.dropdown-item):not(.page-link):not(.text-reset):not(.text-decoration-none):not(.stretched-link) {
  /* Round three of the link look (client, 2026-07-30): the RED underline is
     out too — links are now slightly darker and bolder than body text with a
     normal-color underline; red appears only on hover (which the client
     confirmed they like). The !important on the decoration longhands is
     load-bearing: the vendored bootstrap.min.css declares
     `a{text-decoration:none!important}`, which beats ANY specificity —
     without these, every underline on the site dies silently (which is
     exactly what happened once). The shorthand resets line+color+thickness,
     so all three carry the marker; currentColor keeps the underline in the
     text color through rest AND hover. text-underline-offset is not part of
     the shorthand and needs none. */
  color: #16181b;
  font-weight: 600;
  text-decoration-line: underline !important;
  text-decoration-thickness: 1px !important;
  text-decoration-color: currentColor !important;
  text-underline-offset: 3px;
}
.page-content a:not(.btn):not(.badge):not(.nav-link):not(.dropdown-item):not(.page-link):not(.text-reset):not(.text-decoration-none):not(.stretched-link):hover {
  color: #ec3013;
}

/* A submit button that must sit beside plain-link row actions (e.g. "Login as
   user" next to "Edit" in the admin tables) and look identical to them. A POST
   action cannot be an <a>, so mirror the page-content link look above onto the
   button and strip its native chrome. The `a{text-decoration:none!important}`
   fight the anchors need does not reach <button>, so no !important here. */
.page-content button.link-action {
  padding: 0;
  border: 0;
  background: none;
  font: inherit;
  vertical-align: baseline;
  cursor: pointer;
  color: #16181b;
  font-weight: 600;
  text-decoration-line: underline;
  text-decoration-thickness: 1px;
  text-decoration-color: currentColor;
  text-underline-offset: 3px;
}
.page-content button.link-action:hover { color: #ec3013; }

/* Footer links sit outside .page-content: same treatment, but inherit the
   footer's muted tone rather than forcing near-black into it. */
footer a {
  color: inherit;
  font-weight: 600;
  text-decoration-line: underline !important;
  text-decoration-thickness: 1px !important;
  text-decoration-color: currentColor !important;
  text-underline-offset: 3px;
}
footer a:hover { color: #ec3013; }

/* --- ESL design system (task 14): red primary, dark banner, Archivo brand --- */

/* Primary buttons in brand red. Both the CSS-variable form (Bootstrap >= 5.2
   resolves buttons through --bs-btn-*) and plain properties, so the override
   holds whichever path the vendored build takes. */
.btn-primary {
  --bs-btn-bg: #ec3013;
  --bs-btn-border-color: #ec3013;
  --bs-btn-hover-bg: #c9280f;
  --bs-btn-hover-border-color: #c9280f;
  --bs-btn-active-bg: #b0220a;
  --bs-btn-active-border-color: #b0220a;
  --bs-btn-disabled-bg: #ec3013;
  --bs-btn-disabled-border-color: #ec3013;
  --bs-btn-focus-shadow-rgb: 236, 48, 19;
  background-color: #ec3013;
  border-color: #ec3013;
}
/* !important is load-bearing (codex catch): the vendored app.min.css pins
   .btn-primary hover/focus/active to template blue WITH !important, so a
   normal override wins at rest and loses the moment the button is touched. */
.btn-primary:hover, .btn-primary:focus {
  background-color: #c9280f !important;
  border-color: #c9280f !important;
}
.btn-primary:active, .btn-primary.active {
  background-color: #b0220a !important;
  border-color: #b0220a !important;
}
.btn-primary:focus, .btn-primary:focus-visible {
  box-shadow: 0 0 0 0.25rem rgba(236, 48, 19, 0.3) !important;
}

/* The vendored app.min.css forces .btn-warning text to WHITE
   (`.btn-warning{color:#fff!important}`) on its amber #f4c238 fill — ~1.7:1,
   unreadable in BOTH themes (client catch on the impersonation banner's
   "End impersonation" button, the app's only .btn-warning). Restore
   Bootstrap's own default of BLACK text on warning buttons; !important is
   load-bearing to beat the template's, exactly like .btn-primary above. */
.btn-warning {
  color: #000 !important;
}

/* The banner (top bar with the logo) in the design system's near-black. Every
   header control sits on it, so they all go light. */
.navbar-header {
  background-color: #201e1d;
}
.navbar-header .header-item,
.navbar-header .header-item i,
.navbar-header .fw-medium {
  color: #f2f0ef !important;
}
.navbar-header .header-item:hover {
  color: #ffffff !important;
}
.esl-brand {
  display: flex;
  align-items: center;
  gap: 12px;
  text-decoration: none;
}
.esl-brand img {
  height: 38px;
  width: auto;
  display: block;
}
.esl-brand-name {
  font-family: 'Archivo', sans-serif;
  font-weight: 400;
  font-size: 24px;
  color: #ffffff;
  white-space: nowrap;
}
.esl-brand:hover .esl-brand-name { color: #ffffff; }

/* Header BETA badge (documentation/BetaStage/plan.md) — a subtle plate next to
   the wordmark; red only on hover. #ff7a5c, not #ec3013: the header is dark in
   BOTH themes and #ec3013 sits at ~3.9:1 there (the documented dark-surface
   rule — see the CLAUDE.md dark-mode note and darkmode.css). */
.esl-beta-badge {
  margin-left: 10px;
  padding: 1px 7px 2px;
  border: 1px solid rgba(242, 240, 239, .5);
  border-radius: 4px;
  font-family: 'Archivo', sans-serif;
  font-size: 11px;
  font-weight: 600;
  letter-spacing: .08em;
  line-height: 1.6;
  color: #f2f0ef;
  text-decoration: none !important;
  white-space: nowrap;
}
.esl-beta-badge:hover,
.esl-beta-badge:focus {
  color: #ff7a5c;
  border-color: #ff7a5c;
}

/* Below 992px the vendored app.min.css paints the brand box with
   var(--bs-header-bg) (= #ffffff in the light theme) at specificity 0,3,0 — a
   white plate on our dark header that would swallow the light badge AND
   already swallows the white wordmark in the 768–991px band (a pre-existing
   latent bug; this rule fixes both). 0,4,1 outranks it. */
body[data-layout=horizontal] .ishorizontal-topbar .navbar-header .navbar-brand-box {
  background-color: transparent;
}

/* Red bottom border for the SMALL boxes only (landing sidebars for now — not
   the middle column, not anything wider than 6/12; per the design screenshot). */
.card-accent {
  border-bottom: 3px solid #ec3013;
}

/* --- About section (documentation/AboutPages/plan.md) --------------------- */

/* The FAQ accordion, first use of the component in this app. Bootstrap 5.3
   paints an OPEN header with --bs-primary-bg-subtle / --bs-primary-text-emphasis,
   which the red pass in :root below turned into dark-red text (#b0220a) on a pink
   plate — red heading text is what the client rejected twice for links, and a
   pink plate repeated down a 52-question list is loud. Neutralise both: the text
   follows the body colour and the open row gets a barely-there warm tint. The
   chevron and the focus ring still carry the brand. */
/* LIGHT-MODE DEFINITION (client, 2026-08-02: "in light mode the question boxes
   are hard to see"). The cause is Bootstrap's own default, not our styling:
   --bs-accordion-bg is `transparent`, so an item has NO surface of its own and
   the page shows straight through it — 52 questions separated by nothing but a
   #eff0f2 hairline. Dark mode never had the problem only because it paints
   --bs-accordion-bg: #242220 explicitly.

   So give the component a real surface: a white plate for the answer body, a
   faintly tinted header so each question reads as a box rather than a line of
   text, and a border with enough weight to be seen. All three properties are
   already overridden in darkmode.css at higher specificity, so none of this
   reaches the dark theme, which the client is happy with.

   Values, not brand colours: definition here is a neutral-contrast job. Red on
   a repeated 52-row list is exactly the loudness the active-row note below
   guards against. */
.accordion {
  --bs-accordion-bg: #ffffff;
  --bs-accordion-btn-bg: #f4f6f8;
  --bs-accordion-border-color: #d7dbe0;
  --bs-accordion-active-color: var(--bs-body-color);
  --bs-accordion-active-bg: rgba(236, 48, 19, .05);
  --bs-accordion-btn-focus-box-shadow: 0 0 0 0.2rem rgba(236, 48, 19, .2);
  /* The OPEN chevron: Bootstrap's default data-URI bakes fill='%230c2350' into
     the SVG, one of the template blues the red pass removed everywhere else. A
     baked hex cannot be reached by the :root variables, so it survived — and
     darkmode.css already overrides this same property to #ff7a5c, which left
     the two themes disagreeing about what an open row looks like. */
  --bs-accordion-btn-active-icon: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16' fill='%23ec3013'%3e%3cpath fill-rule='evenodd' d='M1.646 4.646a.5.5 0 0 1 .708 0L8 10.293l5.646-5.647a.5.5 0 0 1 .708.708l-6 6a.5.5 0 0 1-.708 0l-6-6a.5.5 0 0 1 0-.708z'/%3e%3c/svg%3e");
}

/* Deep links (/about/faq#faq-…, the URL the FAQPage JSON-LD publishes for all
   52 questions) land on an .accordion-item. The header is position:fixed, so
   without this the question heading scrolls UNDER it and the visitor arrives
   looking at the middle of an answer. Sized to the measured header: 136px where
   the topbar and .topnav are two stacked rows (>=992px), 77px once .topnav
   collapses into the hamburger — plus a little air. This covers both entry
   paths, the browser's own fragment jump and the view's scrollIntoView(). */
.accordion-item { scroll-margin-top: 90px; }
@media (min-width: 992px) {
  .accordion-item { scroll-margin-top: 150px; }
}

/* Numbered step badge ("The response" on /about/why-esl, "How it works" on
   /about/benefits). White on brand red is the pairing .btn-primary already uses
   site-wide (~4.2:1); the digit is set at 1.25rem/600, which is WCAG "large
   text", where the threshold is 3:1. */
.esl-step-number {
  flex-shrink: 0;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  width: 2.5rem;
  height: 2.5rem;
  border-radius: 50%;
  background-color: #ec3013;
  color: #ffffff;
  font-size: 1.25rem;
  font-weight: 600;
  line-height: 1;
}

/* --- Font-size control (task 15). `zoom` rather than a root font-size bump:
   the vendored template sizes most text with px utilities (font-size-13 etc.)
   that a rem change would not touch, and an "increase font size" button that
   only grows SOME text reads as broken. Zoom scales the page uniformly, like
   the browser's own zoom. --- */
html[data-fontsize="lg"] body { zoom: 1.12; }
html[data-fontsize="xl"] body { zoom: 1.25; }

/* --- Organisation logo carousel (task 16): 6 tiles visible, the track slides
   one tile per second (JS moves the first tile to the end after each step). --- */
.org-carousel { overflow: hidden; }
.org-carousel-track {
  display: flex;
  transition: transform 0.6s ease;
  will-change: transform;
}
.org-carousel-item {
  flex: 0 0 16.6667%;
  max-width: 16.6667%;
  padding: 0 10px;
  text-align: center;
}
.org-carousel-item img {
  max-width: 100%;
  height: 100px;
  object-fit: contain;
}
@media (max-width: 767px) {
  .org-carousel-item { flex: 0 0 33.3333%; max-width: 33.3333%; }
}

/* --- Global red repaint (client feedback 2026-07-29): "all links and buttons
   should be red — globally, not one-by-one."

   Bootstrap 5.3 resolves bare links, .btn-link, .text-primary, .bg-primary,
   .bg-primary-subtle, pagination hover/focus and more through the custom
   properties below, so redefining them recolors every consumer at once —
   including places with no class of their own (the admin tiles' "Details"
   links, the footer, the landing live feed). Values the build BAKED into
   class-local hex (.btn-primary above, .btn-outline-*, the pagination active
   box, form focus tints, checkboxes, the map tooltip) get explicit overrides
   after the variable block. Semantic colors stay untouched: success/danger/
   warning buttons and status/info badges keep their meaning — red everywhere
   would erase what the red ones signal. --- */
:root, [data-bs-theme=light] {
  --bs-primary: #ec3013;
  --bs-primary-rgb: 236, 48, 19;
  --bs-primary-bg-subtle: #fdeae7;
  --bs-primary-border-subtle: #f8b7ab;
  --bs-primary-text-emphasis: #b0220a;
  /* Link REST color is the body color — red text on links reads as broken
     (client, twice; see the text-link rule above). Hover goes brand red, so
     every bare link (admin tiles' "Details", card patterns) still signals. */
  --bs-link-color: var(--bs-body-color);
  --bs-link-color-rgb: var(--bs-body-color-rgb);
  --bs-link-hover-color: #ec3013;
  --bs-link-hover-color-rgb: 236, 48, 19;
}

/* Outline buttons carry their palette in class-local baked vars. .btn-outline-info
   is included: it is another template blue, and the client wants no blue buttons. */
.btn-outline-primary,
.btn-outline-info {
  --bs-btn-color: #ec3013;
  --bs-btn-border-color: #ec3013;
  --bs-btn-hover-color: #fff;
  --bs-btn-hover-bg: #ec3013;
  --bs-btn-hover-border-color: #ec3013;
  --bs-btn-focus-shadow-rgb: 236, 48, 19;
  --bs-btn-active-color: #fff;
  --bs-btn-active-bg: #b0220a;
  --bs-btn-active-border-color: #b0220a;
  --bs-btn-disabled-color: #ec3013;
  --bs-btn-disabled-border-color: #ec3013;
}

/* Pagination (incl. DataTables): the boxes are button-like, so they DO go
   red — and since the link vars now carry body color at rest, hover/focus
   need explicit values besides the baked active box and focus ring. */
.pagination {
  --bs-pagination-hover-color: #ec3013;
  --bs-pagination-focus-color: #c9280f;
  --bs-pagination-active-bg: #ec3013;
  --bs-pagination-active-border-color: #ec3013;
  --bs-pagination-focus-box-shadow: 0 0 0 0.15rem rgba(236, 48, 19, 0.15);
}

/* Form focus tints are baked soft template-blue in this build. */
.form-control:focus,
.form-select:focus {
  border-color: #f3a294;
  box-shadow: 0 0 0 0.15rem rgba(236, 48, 19, 0.15);
}
.form-check-input:checked { background-color: #ec3013; border-color: #ec3013; }
.form-check-input:focus {
  border-color: #f3a294;
  box-shadow: 0 0 0 0.15rem rgba(236, 48, 19, 0.15);
}

/* Native <select> is built by Zend_Form as class="form-control" (never
   .form-select), and the vendored bootstrap reset puts appearance:none on
   .form-control — which strips the OS arrow, so a dropdown looked identical to
   a text field (client, 2026-08-01). Re-add the caret Bootstrap only ships on
   .form-select. :not([multiple]) leaves list boxes alone; dark mode recolours
   the stroke in darkmode.css. */
select.form-control:not([multiple]) {
  background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3e%3cpath fill='none' stroke='%231f2224' stroke-linecap='round' stroke-linejoin='round' stroke-width='2' d='m2 5 6 6 6-6'/%3e%3c/svg%3e");
  background-repeat: no-repeat;
  background-position: right 0.75rem center;
  background-size: 16px 12px;
  padding-right: 2.25rem;
}

/* The DEFAULT progress-bar color is baked too (a bare .progress-bar showed
   template blue on the folder-upload dialog — review catch). Bars carrying an
   explicit bg-* utility keep it: the utility's !important background wins, so
   the two-color download chart keeps its blue ZIP segment. */
.progress, .progress-stacked { --bs-progress-bar-bg: #ec3013; }

/* World-map hover tooltip: the vendored jsvectormap ships it #5c5cff blue, and
   its stylesheet loads AFTER this one (injected by the statistics view), so the
   element selector raises specificity above the vendor's bare class. */
div.jvm-tooltip { background-color: #ec3013; }

/* The banner's black must span the full viewport: the vendored template centers
   .navbar-header at max-width 85%, which left white bands either side. The
   template re-asserts the wrapper background at body[data-layout=horizontal]
   specificity, so a bare class here silently loses — match it. Content keeps
   the template's width; the .topnav row below still lays its own background
   over this. */
body[data-layout=horizontal] .ishorizontal-topbar,
.ishorizontal-topbar { background-color: #201e1d; }

/* Logged-in profile icon reddish: the glyph color lives in the SVG itself
   (img/avatar/generic.svg, only used in the header), the ring here. */
.navbar-header .header-profile-user { border-color: #ec3013; }

/* Topnav hover/focus in brand red (was template blue, pinned by the vendored
   sheet at its own specificity — .nav-link is excluded from the link vars). */
.topnav .navbar-nav .nav-link:hover,
.topnav .navbar-nav .nav-link:focus { color: #ec3013; }

/* The ENTRIES of a topnav dropdown, same story one level down: the vendored
   sheet pins `.topnav .navbar-nav .dropdown-item:hover{color:#1f58c7}` — one of
   the template blues the client removed everywhere — at 0,4,0, which outranks
   both the :root link vars and darkmode.css's own .dropdown-item:hover rule.
   Latent until now because the only topnav dropdown was the admin-only one;
   the About menu puts it in front of every visitor. Red on hover matches the
   parent .nav-link rule directly above.

   :focus is included so keyboard users get the same signal, which the template
   rule does not cover at all. The dark-mode counterpart lives in darkmode.css,
   which has to restate the whole selector: its usual
   `html.theme-dark .dropdown-item:hover` is 0,3,1 and loses to the template's
   0,4,0. */
.topnav .navbar-nav .dropdown-item:hover,
.topnav .navbar-nav .dropdown-item:focus { color: #ec3013; }

/* RESTING colour of those same entries, same specificity problem one step
   earlier. The vendored `.topnav .navbar-nav .dropdown-item{color:#7b8190}`
   (0,3,0) also outranks darkmode.css's `html.theme-dark .dropdown-item` (0,2,1),
   so #7b8190 was the resting colour in BOTH themes: ~3.90:1 on the white menu,
   ~4.07:1 on the dark plate (#242220) — under 4.5:1 at 14px either way. Latent
   while the only topnav dropdown was admin-only; the About menu is the first one
   a visitor sees, and /about/faq itself tells them the site uses
   contrast-checked colours.

   The body colour rather than another gray: it is what the accordion rule above
   already borrows, so there is one place the theme's text colour is decided.
   Red stays on :hover/:focus only — red resting text is what the client rejected
   twice. Dark mode restates this at 0,4,1 in darkmode.css. */
.topnav .navbar-nav .dropdown-item { color: var(--bs-body-color); }

/* RESTING colour of the TOP-LEVEL topnav links (All Projects, AI Assistant,
   Statistics, About, Get Engaged), the same vendored #7b8190 one level up:
   `.topnav .navbar-nav .nav-link{color:#7b8190}` at 0,3,0, which the :root link
   vars cannot reach because .nav-link is excluded from them. ~3.90:1 on the
   white menu bar at 14px — under AA — in LIGHT mode on every page; dark mode has
   been fine since darkmode.css:44-45, whose `html.theme-dark .topnav .nav-link`
   is 0,3,1 and so still wins over this.

   This shipped a commit LATER than the .dropdown-item rule above, which is worth
   knowing when reading the history: that commit drew its line at "fix what it
   newly exposes" (dropdown entries were admin-only until the About menu made
   them public, whereas these links had been public for months) and deferred the
   parent links as a visible change to the site's primary navigation that the
   client had not seen. It left a real inversion in place meanwhile — the About
   menu's entries were higher-contrast than the "About" that opens them.
   **The client approved the fix on 2026-08-02**, so the deferral is closed:
   both levels now take the body colour and the topnav is AA-compliant in both
   themes. That also makes an already-published claim true — /about/faq's
   accessibility answer (Category 6) tells visitors the site uses
   contrast-checked colours.

   Body colour rather than another gray, for the same reason as the rule above:
   one place decides the theme's text colour. Red stays on :hover/:focus only —
   red resting link text is what the client rejected twice. */
.topnav .navbar-nav .nav-link { color: var(--bs-body-color); }

/* EQF level and competence-framework multi-checkboxes
   (Zend_Form_Element_MultiCheckbox renders <label><input>text</label> per
   option, inline). One option per line. */
.eqf-levels label,
.competence-frameworks label {
    display: block;
    margin-bottom: .35rem;
    font-weight: 400;
    cursor: pointer;
}
.eqf-levels label:last-child,
.competence-frameworks label:last-child { margin-bottom: 0; }
.eqf-levels .form-check-input,
.competence-frameworks .form-check-input { margin-right: .5rem; }