/**
 * Luxa Forms — Multi-step Form addon: frontend styling.
 * Only enqueued on pages where core rendered a [luxa_form]/block that
 * actually contains a Page Break field (see StepRenderer.php).
 */

/**
 * Core wraps WHATEVER the 'lxf_fields_html' filter returns inside a
 * single <div class="lxf-fields"> — a `display:flex; flex-wrap:wrap;`
 * row meant to hold individual .lxf-field elements side by side
 * according to their own width-25/33/50/66/75/100 class (see the free
 * plugin's frontend.css). StepRenderer::render_steps() completely
 * REPLACES that filter's output with its own top-level blocks instead
 * — one .lxf-ms-progress bar, then one .lxf-step per step — and those
 * are block-level containers, not individual fields. Without an
 * explicit width, a flex item defaults to shrinking to its own
 * content width (`flex: 0 1 auto`), so the progress bar and every
 * step ended up only as wide as their own content demanded, floating
 * inside the outer flex row instead of each spanning the form's full
 * width — the "cramped/narrow" look. Forcing width: 100% here makes
 * each one consume its entire flex row on its own (and, combined with
 * flex-wrap: wrap on the parent, pushes anything after it onto the
 * next line) — restoring the full 720px .lxf-form-wrap width these
 * were always meant to have. This is scoped with the `.lxf-fields >`
 * child selector specifically, rather than a bare `.lxf-ms-progress,
 * .lxf-step { width:100% }`, so it only ever affects these elements
 * in their ACTUAL rendered position (direct children of core's flex
 * container) and can't accidentally clobber width if either class
 * name is ever reused inside some other, unrelated layout context.
 */
.lxf-fields > .lxf-ms-progress,
.lxf-fields > .lxf-step {
    width: 100%;
}

.lxf-ms-progress {
    margin-bottom: 1.5rem;
}
.lxf-ms-progress__list {
    display: flex;
    list-style: none;
    margin: 0;
    padding: 0;
    counter-reset: none;
}
.lxf-ms-progress__item {
    flex: 1 1 0;
    display: flex;
    flex-direction: column;
    align-items: center;
    text-align: center;
    position: relative;
    color: #9ca3af;
}
.lxf-ms-progress__item:not(:last-child)::after {
    content: '';
    position: absolute;
    top: 14px;
    left: 50%;
    width: 100%;
    height: 2px;
    background: #e5e7eb;
    z-index: 0;
}
.lxf-ms-progress__item.is-done:not(:last-child)::after {
    background: #2563eb;
}
.lxf-ms-progress__num {
    position: relative;
    z-index: 1;
    display: flex;
    align-items: center;
    justify-content: center;
    width: 28px;
    height: 28px;
    border-radius: 999px;
    background: #e5e7eb;
    color: #6b7280;
    font-size: .8125rem;
    font-weight: 600;
    margin-bottom: .375rem;
}
.lxf-ms-progress__item.is-current .lxf-ms-progress__num {
    background: #2563eb;
    color: #fff;
}
.lxf-ms-progress__item.is-done .lxf-ms-progress__num {
    background: #16a34a;
    color: #fff;
}
.lxf-ms-progress__label {
    font-size: .75rem;
    line-height: 1.2;
}
.lxf-ms-progress__item.is-current .lxf-ms-progress__label {
    color: #111827;
    font-weight: 600;
}

.lxf-step {
    /* Second half of the same underlying issue as the .lxf-fields >
       .lxf-step rule at the top of this file: core's OWN .lxf-field
       (in an ordinary, single-page form) lays out side by side via
       its .lxf-fields ancestor being display:flex — that's what
       makes a field set to width-50/33/25 actually sit next to its
       neighbor instead of just being a half-width block on its own
       line. Once StepRenderer moves each field to be a DIRECT CHILD
       of .lxf-step instead of .lxf-fields, that flex context is gone
       unless re-established HERE — without it, two fields both set
       to 50% width inside the same step would each still take a
       full line of their own (a `width: 50%` block-level <div> has
       no side-by-side behavior on its own; that's what a flex/grid
       parent provides). Mirrors .lxf-fields's own
       `display:flex; flex-wrap:wrap; gap:1rem;` exactly, so a field's
       width-* class behaves identically whether it's on an ordinary
       form or inside one particular step of a multi-step form. */
    display: flex;
    flex-wrap: wrap;
    gap: 1rem;
    animation: lxf-ms-fade-in .2s ease;
}
@keyframes lxf-ms-fade-in {
    from { opacity: 0; transform: translateY(4px); }
    to   { opacity: 1; transform: translateY(0); }
}

.lxf-ms-nav {
    /* .lxf-ms-nav sits inside the now-flex .lxf-step alongside the
       field wrappers above it — without spanning the full row itself,
       it would just become another flex item shrunk to its own
       content width and could end up squeezed next to the LAST
       field instead of on its own row below all of them. */
    width: 100%;
    display: flex;
    justify-content: space-between;
    gap: .75rem;
    margin-top: 1.25rem;
}
.lxf-ms-nav:has(.lxf-ms-prev):not(:has(.lxf-ms-next)) {
    justify-content: flex-start;
}
.lxf-ms-nav .lxf-ms-next,
.lxf-ms-nav .lxf-ms-prev {
    margin-left: 0;
}
/* On the FIRST step there's no Back button — push Next to the right
   on its own without relying on :has() support. */
.lxf-step[data-step="0"] .lxf-ms-nav {
    justify-content: flex-end;
}

@media (max-width: 480px) {
    .lxf-ms-progress__label { display: none; }
}

/* ==========================================================================
   Progress style: "bar" — single percentage bar, no per-step markers.
   Sibling to the original .lxf-ms-progress__list ("steps" style) above.
   ========================================================================== */
.lxf-ms-progress--bar .lxf-ms-progress__track {
    height: 8px;
    border-radius: 999px;
    background: #e5e7eb;
    overflow: hidden;
}
.lxf-ms-progress--bar .lxf-ms-progress__fill {
    height: 100%;
    background: #2563eb;
    border-radius: 999px;
    transition: width 0.25s ease;
}
.lxf-ms-progress--bar .lxf-ms-progress__text {
    margin: 0.5rem 0 0;
    font-size: 0.875rem;
    color: #6b7280;
    text-align: right;
}