/*
 * DRAFT custom CSS for the LimeSurvey "extends_fruity_twentythree" custom
 * theme (a "Тема користувача" extending "Fruity TwentyThree" /
 * fruity_twentythree, per the Configuration -> Themes list).
 *
 * Colors, typography, buttons, and focus states below are ported from the
 * Bureau's real institutional design system, read directly from:
 *   - /Users/miry4_Dev/Documents/lgbt-bureau/DESIGN.md (color roles, type
 *     hierarchy, button/card/focus rules)
 *   - /Users/miry4_Dev/Documents/lgbt-bureau/assets/css/main.css (exact
 *     :root token values, .btn-primary/.btn-outline-navy rules, the real
 *     focus-visible outline used on the public site)
 * These are the same navy/gold tokens documented in DESIGN.md section 2 —
 * not invented here. Touch-target sizing, focus-visibility, and container
 * width still follow docs/limesurvey-accessible-theme-ux-specification.md
 * (Gate G-05, still draft/not yet reviewed) since those are accessibility
 * requirements, not brand requirements, and apply regardless of palette.
 *
 * Selectors below (2026-07-07, second pass) are verified against the real
 * rendered page source the human maintainer shared — not guessed. Actual
 * markup structure for one question (List Radio):
 *   <div class="row list-radio mandatory question-container" id="question252">
 *     <div class="question-title-container col-12">
 *       <div class="question-text"><div class="ls-label-question">...</div></div>
 *     </div>
 *     <div class="question-valid-container ... col-12">
 *       <div class="ls-questionhelp"><div class="ls-question-message ls-em-tip em_default">
 *         Виберіть одну з наступних відповідей
 *       </div></div>
 *     </div>
 *     <div class="answer-container col-12">
 *       <ul class="ls-answers answers-list radio-list list-unstyled">
 *         <li class="answer-item radio-item">
 *           <input type="radio" ...><label class="control-label radio-label">...</label>
 *         </li>
 *       </ul>
 *     </div>
 *   </div>
 * Next/submit button: <button id="ls-button-submit" class="ls-move-btn
 * ls-move-next-btn ls-move-submit-btn action--ls-button-submit btn btn-lg
 * btn-primary">. Note "ls-button-submit" is an ID, not a class — an earlier
 * draft of this file wrongly used it as `.ls-button-submit`.
 * Outer page layout: <div class="outerframe container-fluid"><div
 * class="row"><div class="col-centered col-xl-8"><div id="main-row"><div
 * class="col-centered space-col" id="main-col">...form...</div></div>
 * </div></div></div> — `.question-container` is ITSELF a Bootstrap `.row`
 * (Bootstrap rows carry negative left/right margins for gutters). An
 * earlier draft applied `max-width` + `margin: auto` directly to
 * `.question-container`, which fought with those negative margins and
 * produced an asymmetric shift (content pushed right, empty space on the
 * left) — this is fixed below by centering `#main-col` instead, which is
 * not itself a `.row`.
 *
 * Font note: the Bureau's main site loads Montserrat from Google Fonts,
 * which the accessible-theme spec's "no external visual dependencies" rule
 * would not allow for the survey. `sites/survey-lgbt-in-ua/styles.css` (this
 * repo) already solved that same tension by self-hosting Montserrat as
 * local .woff2 files via @font-face. This file assumes the same self-hosted
 * fonts are NOT yet uploaded into this LimeSurvey theme, so it falls back to
 * `Montserrat, system-ui, sans-serif` — if Montserrat isn't installed/
 * uploaded to the LimeSurvey theme, browsers will silently use system-ui
 * instead. Ask if you want the actual .woff2 files prepared for upload.
 *
 * How to use (human-only step, per ADR-005 — paste this yourself):
 *   Confirmed correct target (Theme Editor -> "Файли CSS:" section): open
 *   `custom.css` and paste this file's CSS rules directly — no wrapper
 *   tags, just the plain CSS below. Save, then check "Перегляд" (Preview).
 */

:root {
  --navy: #0e1e40;
  --navy-deep: #0a1733;
  --gold: #d7a40a;
  --gold-hover: #b8890a;
  --light: #f8f9fb;
  --white: #ffffff;
  --text: #374151;
  --text-light: #6b7280;
  --border: #e5e7eb;
}

body {
  font-family: "Montserrat", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
  color: var(--text);
  background: var(--light);
  font-size: 18px;
  line-height: 1.6;
}

/* Layout centering: applied to #main-col (not `.question-container`, which
   is itself a Bootstrap `.row` with negative gutter margins — see the
   comment above for why that caused an asymmetric shift). */
#main-col {
  max-width: 760px;
  margin-left: auto !important;
  margin-right: auto !important;
  float: none;
}

@media (max-width: 768px) {
  #main-col {
    max-width: 100%;
    padding-left: 16px;
    padding-right: 16px;
  }
}

/* Outer wrapper centering (2026-07-07, fourth pass): confirmed against a
   real full page source (welcome screen and a question-group page) that
   #main-col sits inside a SEPARATE, wider wrapper -
   #outerframeContainer > .row > .col-centered.col-xl-8 > #main-row >
   #main-col - and that outer `.row` carries no `justify-content-center`
   class (unlike the progress-bar's own `.row.justify-content-center`
   higher up the page). A Bootstrap `.row` is a flex container; a lone
   `.col-xl-8` inside it with no centering utility and no margin:auto
   defaults to flex-start, hugging the left edge with the remaining ~1/3 of
   the viewport empty on the right - reported directly by the human
   maintainer as an accessibility problem (very large blank area, content
   not using available reading width) on a wide screen. Centering #main-col
   alone was not enough because this OUTER box was never centered in the
   first place. Fixed the same proven way as #main-col: margin:auto is a
   valid centering technique for a flex item, not just a floated/block box. */
#outerframeContainer > .row > .col-centered {
  margin-left: auto !important;
  margin-right: auto !important;
  float: none;
}

/* Each question's card: white surface, subtle navy-tinted border and
   shadow, matching DESIGN.md's card language (section 4) and main.css's
   `rgba(14,30,64,.08)` / `rgba(14,30,64,.12)` tokens. */
.question-container {
  background: var(--white);
  border: 1px solid rgba(14, 30, 64, 0.12);
  border-radius: 12px;
  box-shadow: 0 2px 16px rgba(14, 30, 64, 0.08);
  padding: 20px;
  margin-bottom: 16px;
}

/* Question text: navy, matching how the Bureau site treats section/card
   titles. Spec recommends 20-22px desktop, 18-20px mobile. Targets the
   actual label div, not just its wrapper, so size/weight/color apply even
   if the wrapper itself carries no visible text. */
.question-text,
.ls-label-question,
.group-title {
  font-size: 22px;
  line-height: 1.4;
  font-weight: 700;
  color: var(--navy);
}

@media (max-width: 768px) {
  .question-text,
  .ls-label-question,
  .group-title {
    font-size: 20px;
  }
}

@media (max-width: 480px) {
  .question-text,
  .ls-label-question,
  .group-title {
    font-size: 18px;
  }
}

/* Text-display ("boilerplate") questions — intro/informational paragraphs
   like the consent screen — get the outer class `boilerplate` on
   `.question-container` (confirmed in LimeSurvey's own source:
   `Question::getQuestionClass()` in application/models/Question.php
   returns 'boilerplate' for question type X). These are body copy, not a
   short question title, so the bold navy 22px rule above (correct for
   actual questions like list-radio) reads as a dense "wall of bold text"
   here — override it back to normal body-text styling, matching
   DESIGN.md's 1.6-1.7 line-height for long-form Ukrainian text. */
.question-container.boilerplate .ls-label-question {
  font-size: 18px;
  line-height: 1.7;
  font-weight: 400;
  color: var(--text);
}

/* Instruction/validation text ("Виберіть одну з наступних відповідей" and
   similar) — this lives in .ls-question-message, not a ".question-help"
   class (that class does not exist in the real markup; an earlier draft
   targeted it and had no effect). Muted, still readable at 16px minimum. */
.ls-question-message,
.ls-questionhelp,
.question-help-container {
  font-size: 16px;
  line-height: 1.5;
  color: var(--text-light);
  font-style: normal;
}

/* Long option lists (e.g. D2's 30 region options) span many screens in a
   single column. Automatically switch to multiple columns once a list has
   many items, so scanning them doesn't require excessive scrolling. Uses
   :has() to detect item count rather than targeting any specific question
   by ID — LimeSurvey reassigns internal question IDs on every import, so a
   hardcoded ID selector would silently stop working after a re-import.
   The real fix (LimeSurvey's native "number of answer columns" question
   attribute) needs the `question_attributes` XML block, which the
   generator does not yet emit (DIT-002, already logged and deferred).
   Gracefully degrades to a normal single column on browsers without
   :has() support (Safari <15.4, Firefox <121) — not a functional break. */
/* Tag-qualified (`ul.ls-answers`, not bare `.ls-answers`): LimeSurvey's
   Array (Flexible Labels) question puts the SAME class on its own
   <table class="ls-answers ... table table-bordered ...">, and CSS
   multi-column layout on a <table> produces broken/unpredictable
   rendering (confirmed 2026-07-07 against P1's real markup, TASK-135 -
   this was part of the root cause of the array-table squish, alongside
   the .answer-item fix below). Scoping to `ul` matches the real List
   Radio markup exactly and leaves the Array table untouched. */
ul.ls-answers {
  column-fill: balance;
}

@media (min-width: 640px) {
  ul.ls-answers:has(li:nth-child(11)) {
    column-count: 2;
    column-gap: 24px;
  }
}

@media (min-width: 900px) {
  ul.ls-answers:has(li:nth-child(21)) {
    column-count: 3;
  }
}

/* Whole answer row clickable + comfortable touch target (44px minimum).
   margin: 0 resets any base-theme spacing between <li> rows so padding
   here is the only spacing source, avoiding compounded/oversized gaps.
   Tag-qualified (`li.answer-item`, not bare `.answer-item`): LimeSurvey's
   Array (Flexible Labels) question (e.g. P1) puts the SAME class on its
   own <td class="answer_cell_N answer-item radio-item"> table cells.
   `display: flex` on a <td> makes it stop behaving as a table cell at
   all, collapsing the whole array table into a squished single column
   (confirmed 2026-07-07 against P1's real markup, TASK-135). Scoping to
   `li` matches the real List Radio markup exactly (`<li class="answer-item
   radio-item">`) and leaves the Array table's native Bootstrap table
   layout untouched. */
li.answer-item {
  min-height: 44px;
  margin: 0;
  display: flex;
  align-items: center;
  padding: 10px 12px;
  border-radius: 8px;
  cursor: pointer;
  break-inside: avoid;
}

li.answer-item:hover {
  background: rgba(14, 30, 64, 0.04);
}

li.answer-item label,
li.answer-item .control-label {
  cursor: pointer;
  width: 100%;
  margin: 0;
  font-weight: 400;
  color: var(--text);
}

/* Native radio/checkbox controls: larger touch target, gold accent instead
   of the default gray browser control, matching the Bureau's gold-accent
   convention for selected/interactive states (DESIGN.md section 2).
   Tag-qualified for the same reason as li.answer-item above - the Array
   table's <td> radios must keep their native small size to fit an 8.4%-
   wide table column; forcing them to 20px here previously would have
   overflowed/cramped the array table's cells. */
li.answer-item input[type="radio"],
li.answer-item input[type="checkbox"] {
  width: 20px;
  height: 20px;
  margin-right: 12px;
  flex-shrink: 0;
  accent-color: var(--gold);
}

/* Buttons: gold background / navy text / 700 weight / 8px radius, matching
   main.css's .btn-primary exactly (same padding, hover darken + lift).
   #ls-button-submit is the real ID on the Next/Submit button; .ls-move-btn
   is the real shared class for all navigation buttons (Next/Previous). */
#ls-button-submit,
.ls-move-btn {
  min-height: 44px;
  padding: 14px 28px;
  font-size: 15px;
  font-weight: 700;
  font-family: "Montserrat", system-ui, sans-serif;
  background: var(--gold);
  color: var(--navy);
  border: 2px solid transparent;
  border-radius: 8px;
  transition: background-color 0.15s ease, transform 0.15s ease;
}

#ls-button-submit:hover,
.ls-move-btn:hover {
  background: var(--gold-hover);
  transform: translateY(-2px);
  color: var(--navy);
}

/* Visible keyboard focus that does not rely on color alone — same rule and
   same gold token/opacity as the Bureau's real public-site focus state
   (main.css: outline: 3px solid rgba(215,164,10,.72); outline-offset: 3px). */
a:focus-visible,
button:focus-visible,
input:focus-visible,
textarea:focus-visible,
select:focus-visible,
li.answer-item input:focus-visible ~ label {
  outline: 3px solid rgba(215, 164, 10, 0.72);
  outline-offset: 3px;
}

/* "Prefer not to answer" options should look like ordinary answers.
   If this survey marks such options with a distinct class, style it
   identically to a normal answer row here rather than as a warning. */

/* ============================================================
   Welcome/first-page screen (2026-07-07, third pass)
   A completely different template from the question pages above —
   verified against its own real page source. Real structure:
   #welcome-container > h1.survey-name.large-heading (title),
   .survey-description/.survey-welcome (both empty, intentionally),
   .number-of-questions > .question-count-text ("У цьому опитуванні є
   124 питань."). Separately, LimeSurvey's own built-in anonymity notice
   (shown because the survey's `anonymized` setting is Y — this is
   LimeSurvey system text, not this project's content):
   .privacy > .ls-privacy-block > .ls-privacy-head (+ Bootstrap's own
   `.text-uppercase` utility class, which is what forced the all-caps
   look, not anything in this file) and .ls-privacy-body (paragraphs).
   None of these classes were targeted before, so this screen rendered
   with the theme's own defaults: `.large-heading` pulls in IBM Plex
   Serif (ibm-serif.css, loaded in <head>) instead of Montserrat.
   ============================================================ */

.survey-name,
.large-heading {
  font-family: "Montserrat", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
  font-size: clamp(24px, 3vw, 36px);
  font-weight: 800;
  line-height: 1.3;
  color: var(--navy);
}

.question-count-text {
  font-size: 16px;
  color: var(--text-light);
  margin-top: 8px;
}

.privacy {
  margin-top: 8px;
}

.ls-privacy-block {
  background: var(--white);
  border: 1px solid rgba(14, 30, 64, 0.12);
  border-radius: 12px;
  box-shadow: 0 2px 16px rgba(14, 30, 64, 0.08);
  padding: 20px;
}

.ls-privacy-head {
  font-family: "Montserrat", system-ui, sans-serif;
  font-size: 18px;
  font-weight: 700;
  color: var(--navy);
  /* !important needed: real markup carries Bootstrap's own
     `.text-uppercase` utility class alongside `.ls-privacy-head`
     (`class="ls-privacy-head text-uppercase"`), and Bootstrap utilities
     define `text-transform: uppercase !important` - a plain override here
     was silently losing to it (confirmed 2026-07-07 against real markup;
     the all-caps look was never actually fixed by the third pass below). */
  text-transform: none !important;
  margin-bottom: 8px;
}

.ls-privacy-body {
  font-size: 16px;
  line-height: 1.6;
  color: var(--text);
  margin-bottom: 12px;
}

.ls-privacy-body:last-child {
  margin-bottom: 0;
}