/**
 * Customer support / FAQ page (page 2151).
 *
 * The page markup is Greenshift; only the tab layer and the responsive pass live here.
 * Everything the original mockup styled (hero, cards, accordion, form) is still carried by
 * Greenshift dynamicGClasses in post_content — do not duplicate those rules here, or the two
 * sources will drift. This file owns the tabs and the breakpoints, nothing else.
 */

/* ---- Tab bar ---- */
.ryuk-faq-tabs {
    display: flex;
    flex-wrap: wrap;
    gap: 8px;
    margin: 0 0 20px;
    padding: 0;
    list-style: none;
}

.ryuk-faq-tab {
    flex: 1 1 0;
    min-width: 0;
    padding: 12px 14px;
    background: #ffffff;
    border: 1px solid #eaeaec;
    border-radius: 8px;
    font-family: inherit;
    font-size: 14px;
    font-weight: 600;
    line-height: 1.4;
    color: #575757;
    text-align: center;
    cursor: pointer;
    transition:
        border-color 0.2s ease,
        background 0.2s ease,
        color 0.2s ease;
}

.ryuk-faq-tab:hover {
    border-color: #d4aa73;
    color: #1a1a1a;
}

/* Selected state is driven by aria-selected, so the accessible state and the visible state
   can never disagree — there is no separate .active class to forget to update. */
.ryuk-faq-tab[aria-selected="true"] {
    background: #1a1a1a;
    border-color: #1a1a1a;
    color: #ffffff;
}

.ryuk-faq-tab:focus-visible {
    outline: 2px solid #d4aa73;
    outline-offset: 2px;
}

/* ---- Panels ----
   The initial state is CSS, not a `hidden` attribute in the markup. A programmatic post update
   silently dropped `hidden` from the panel divs once already (KSES was not the cause — the user
   had unfiltered_html), and a tab set that depends on an attribute surviving every future write
   is a tab set that breaks quietly. Sibling selector = "every panel after the first". */
.ryuk-faq-panel ~ .ryuk-faq-panel {
    display: none;
}

/* Once the script has initialised it adds .ryuk-faq-js and [hidden] becomes the single source of
   truth. Same specificity as the rule above (0,2,0), so it must stay below it to win the tie. */
.ryuk-faq-js .ryuk-faq-panel {
    display: block;
}

.ryuk-faq-js .ryuk-faq-panel[hidden] {
    display: none;
}

.ryuk-faq-panel:focus {
    outline: none;
}

/* ---- Answer typography ----
   Answers render at #575757. Inherited <b> at that weight barely separates from the body text,
   and a link is not identifiable at all, so both are pulled to the near-black used for questions.
   Bullet lines are plain ・ + <br> rather than a <ul>: the answer is a <p>, and a list element
   inside it is invalid HTML that browsers resolve by closing the paragraph early. */
.ryuk-faq-a b,
.ryuk-faq-a strong {
    color: #1a1a1a;
}

.ryuk-faq-a a {
    color: #1a1a1a;
    text-decoration: underline;
    text-underline-offset: 2px;
    transition: color 0.2s ease;
}

.ryuk-faq-a a:hover {
    color: #d4aa73;
}

/* ---- Responsive ---- */

/* The two cards sit side by side; below this the FAQ column gets too narrow for Japanese
   question text to stay on two lines. */
@media (max-width: 960px) {
    .ryuk-faq-grid {
        grid-template-columns: 1fr;
        padding-left: 24px;
        padding-right: 24px;
    }
}

@media (max-width: 782px) {
    .ryuk-faq-hero {
        padding: 44px 24px 38px;
    }
    .ryuk-faq-title {
        font-size: 30px;
    }
    .ryuk-faq-lede {
        font-size: 16px;
    }
}

@media (max-width: 600px) {
    .ryuk-faq-grid {
        padding: 32px 16px 48px;
        gap: 20px;
    }
    .ryuk-faq-card--faq {
        padding: 12px 20px 20px;
    }
    .ryuk-faq-card--contact {
        padding: 26px 20px 24px;
    }
    .ryuk-faq-card-title {
        font-size: 22px;
    }
    .ryuk-faq-title {
        font-size: 26px;
    }
    /* Japanese tab labels are short enough to stay on one row down to 320px, so they keep
       shrinking rather than stacking — stacking would push the answers below the fold. */
    .ryuk-faq-tab {
        padding: 10px 8px;
        font-size: 13px;
    }
    .ryuk-faq-qtext {
        font-size: 15px;
    }
    .ryuk-faq-a {
        padding-right: 8px;
    }
}

/* ---- Fluent Forms (form 5) ----
   The form ships a 2-column row and a 24% submit button set in the block's own customCss.
   Both break under ~600px, and that customCss is inline in post_content where it is easy to
   miss; overriding here keeps the fix with the rest of the page's breakpoints. */
@media (max-width: 600px) {
    .fluentform .ff-el-group.ff-el-form-hide-label .ff-el-input--label {
        margin-bottom: 6px;
    }
    .fluentform .ff_columns_total_2 > .ff-t-cell {
        flex: 0 0 100%;
        max-width: 100%;
        padding-right: 0;
        padding-left: 0;
    }
    .fluentform .ff-t-container {
        display: block;
    }
    /* The block's own customCss sets width:24% with a (0,6,0) selector, from an inline <style>
       that loads after this file - an equal-specificity rule loses on source order. Scoping under
       .ryuk-faq-page reaches (0,7,0) and wins. Measured before the fix: 76px button on a 316px
       form at 390px viewport. */
    .ryuk-faq-page
        .fluentform.fluentform_wrapper_5.ff_guten_block.ff_guten_block-5
        .ff_submit_btn_wrapper
        .ff-btn-submit {
        width: 100%;
    }
}

/* ---- Side-nav shell (shared maillage) ----
   The FAQ carries the same left navigation as the policy pages. The hero stays full width; below
   it the nav sits beside the existing two-card grid. The grid's own max-width / margin / padding
   are neutralised so the shell owns the outer width — those values live in the page's Greenshift
   dynamicGClasses at (0,1,0), which this (0,2,0) selector beats at every breakpoint, media queries
   included. Nav styling itself comes from the shared content-layout.css. */
.ryuk-faq-shell {
    /* Wider than the 1400 it started at: the 248px nav + 44px gap eat ~292px of the row, so the
       two-card content column had shrunk vs. the pre-maillage layout. 1480 gives that width back
       (~1148px of content) without pushing line length past comfortable reading. */
    max-width: 1480px;
    margin: 0 auto;
    padding: 48px 32px 72px;
    display: grid;
    grid-template-columns: 248px minmax(0, 1fr);
    gap: 44px;
    align-items: start;
}

/* min-width:0 all the way down, or the contact form's min-content (its input row) forces the grid
   wider than the shell track and the whole thing overflows on mobile. */
.ryuk-faq-shell .ryuk-faq-grid,
.ryuk-faq-shell .ryuk-faq-card {
    min-width: 0;
}

.ryuk-faq-shell .ryuk-faq-grid {
    max-width: none;
    margin: 0;
    padding: 0;
}

/* Stack the nav above the content at 1200, not 900: between those widths the 248px nav left the
   two-card grid (a form column + an FAQ column) too narrow, which is exactly what looked cramped at
   1024px. Above 1200 there is room for both side by side. minmax(0,1fr), not 1fr: a bare 1fr track
   floors at min-content, and the nav strip + form would push it past the viewport; minmax(0,…) lets
   the track shrink and the nav scroll. */
@media (max-width: 1200px) {
    .ryuk-faq-shell {
        grid-template-columns: minmax(0, 1fr);
        gap: 24px;
        padding: 40px 24px 56px;
    }
}

@media (max-width: 600px) {
    .ryuk-faq-shell {
        padding: 32px 16px 44px;
    }
}