/*
 * ll-form-skin.css — the last mile of production parity for engine-rendered forms.
 *
 * WHAT THIS FILE IS FOR, AND WHAT IT IS NOT FOR.
 *
 * Almost all of production's form appearance is restored without any CSS at all:
 * the renderer emits the same class names the Contact Form 7 form body used to
 * emit (`.field-row`, `.col-lg-6`, `.field-input`, `.form-btn`, `.btn-primary`),
 * ON TOP of its own `ll-form__*` vocabulary, and the theme's existing rules —
 * which are keyed on ancestors that never went anywhere — apply again by
 * themselves. That is deliberate: those rules carry per-template values (31px on
 * hiring, 35px on positions, 0 on sections) that a stylesheet written here would
 * have had to re-derive one page at a time, and get wrong.
 *
 * So this file holds ONLY what has no existing hook. Every rule below names the
 * measurement that justifies it. If you are about to add a rule here, check first
 * whether emitting a class the theme already styles would do it instead.
 *
 * Loaded at priority 101 from functions.php, after the ~25 perf modules enqueue
 * their bundles at 100, so it is last in the head on bundled and unbundled
 * templates alike. It must never be folded into a *.min.css bundle.
 *
 * Scope: `.ll-form--bs` — the modifier a form carries when its definition sets
 * `layout => bootstrap`. The block-rendered families (contact_lead, landing_lead,
 * fitness_lead) are already pixel-identical to production and must not be touched
 * by anything in here.
 */

/* -----------------------------------------------------------------------------
 * Submit button colour: #1690D3, the colour of a button that WORKS.
 *
 * Measured across all fourteen production fixtures, and the numbers settle an
 * argument I had first got wrong from a sample of two:
 *
 *   #1690D3  cf7_about, cf7_hero, cf7_solutions_alt, cf7_standard, cf7_whitepaper
 *            — and all four theme-rendered families
 *   #29c300  cf7_article, cf7_solutions, cf7_no_consent_tel
 *   #0d6efd  cf7_case_study      (Bootstrap's own default)
 *   transparent                  cf7_contact_us
 *
 * Four colours for one component. The cause is that production's submit is
 * `disabled` on load — a theme script whose re-enable line is commented out — and
 * which rule wins in that state depends on the template's ancestors. Green is not
 * "the enabled colour"; it is simply what shows where the disabled rule cannot
 * reach.
 *
 * The tell is the four families whose buttons are NOT disabled, because they are
 * rendered by the theme's own block forms: every one of them is #1690D3. That is
 * the site's working primary button, and it is what the majority of CF7 pages show
 * too.
 *
 * So: un-break the button, and paint it the colour a working button has. The three
 * families that currently show green, Bootstrap blue or nothing at all change — and
 * they change TOWARDS what the design intends rather than away from it.
 * -------------------------------------------------------------------------- */
.ll-form--bs .ll-form__submit,
.ll-form--bs .ll-form__submit:focus {
	background-color: #1690d3;
	border-color: #1690d3;
	color: #fff;
}

.ll-form--bs .ll-form__submit:hover {
	background-color: #1d78ab;
	border-color: #1d78ab;
	color: #fff;
}

/*
 * Measured: production's button is 230px wide and the engine's was 220. Same font,
 * same size, same 9px/65px padding, same ten characters — the whole difference was
 * `letter-spacing: 1px`, which production picks up from a rule keyed on
 * `input.btn` that a `<button>` cannot match. One pixel per character.
 */
.ll-form--bs .ll-form__submit {
	letter-spacing: 1px;
}

/* -----------------------------------------------------------------------------
 * No arrow on the button.
 *
 * Production's submit is `<input type="submit">`, which cannot contain an icon.
 * The engine's is a `<button>` and ships an arrow glyph. Measured 10px of extra
 * width from it. The spinner stays — it is behaviour, not decoration, and it is
 * hidden until the form is actually submitting.
 * -------------------------------------------------------------------------- */
.ll-form--bs .ll-form__submit-icon {
	display: none;
}

/* -----------------------------------------------------------------------------
 * Consent line.
 *
 * Production renders it as `p.text-center.p-0` — a centred paragraph, the
 * statement, a line break, the link, then the checkbox and its `*`. The engine's
 * label is a flex row, which puts everything on one line and pins the box to the
 * left. `display: block` hands the line back to normal text flow so the `<br>` the
 * renderer emits does what it does on production.
 * -------------------------------------------------------------------------- */
.ll-form--bs .ll-form__consent {
	display: block;
	text-align: center;
}

.ll-form--bs .ll-form__consent input[type="checkbox"] {
	/* Measured on production: baseline alignment. The box sits directly after the
	 * link text, and `vertical-align: middle` lifted it 3px. */
	display: inline-block;
	/*
	 * The inset is Contact Form 7's own, and it is 1em. `.wpcf7-list-item
	 * { margin: 0 0 0 1em }` (contact-form-7/includes/css/styles.css) wraps
	 * production's checkbox in 16px of left margin; the engine's pages do not load
	 * that stylesheet, and a literal text-node space measures 4.2px. That 11.8px is
	 * the largest of the three pieces that left the consent checkbox 6px left of
	 * production's on every bootstrap family — under the harness's 6px x-tolerance
	 * on all of them but `cf7_solutions`, where a second cause pushed it over.
	 *
	 * CF7's value, not a tuned one: what production has here is that stylesheet.
	 */
	margin: 0 0 0 1em;
	vertical-align: baseline;
}

/*
 * And CF7 puts a space on either side of the asterisk, with pseudo-elements:
 * `.wpcf7-list-item-label::before, ::after { content: " " }`. Measured, production's
 * label span is 10.39px for the single character `*` where ours is 6.19 — one
 * space of visible width, because the trailing one collapses at the end of the
 * line. So one `::before`, matching the measurement rather than the symmetry of
 * the rule it mirrors.
 */
.ll-form--bs .ll-form__consent-suffix::before {
	content: " ";
}

.ll-form--bs .ll-form__consent-text {
	display: inline;
}

/* -----------------------------------------------------------------------------
 * Captcha spacing.
 *
 * The Turnstile widget is an addition to these pages — production has no captcha
 * on five of the CF7 families, and the owner ruled that security stays STRICTER
 * than production rather than matching it. It still has to sit in the layout like
 * it belongs there rather than jamming against the consent line.
 * -------------------------------------------------------------------------- */
/*
 * Only centring. The vertical spacing comes from the plugin's own
 * `.cf7-cf-turnstile` rule, which the renderer now emits — including the
 * `margin-bottom: -15px` production relies on. A margin-top invented here fought
 * that rule and put the submit 15px low on 483 pages.
 */
.ll-form--bs .ll-form__captcha {
	display: flex;
	justify-content: center;
}

/* -----------------------------------------------------------------------------
 * The phone field's country selector fills its column.
 *
 * intl-tel-input wraps the input in an inline-block `.iti`, which shrinks to its
 * content — measured at 244px where production is 430. The input's own `w-100` is
 * 100% OF THAT WRAPPER, so it shrinks with it and the field ends up 186px short of
 * its column. The theme's block skin already carries this exact rule for
 * `.ll-form__row--phone .iti`; the CF7 families had no equivalent.
 * -------------------------------------------------------------------------- */
.ll-form--bs .ll-form__row--phone .iti {
	width: 100%;
}

/* -----------------------------------------------------------------------------
 * Captcha spacing, measured rather than invented.
 *
 * Production's `.cf7-cf-turnstile` carries `margin-bottom: -15px`, and that is
 * exactly how much too low the submit button sat. The renderer emits the class,
 * but the rule lives in an inline `<style>` the plugin prints only when Contact
 * Form 7 renders — which it no longer does — so the value has to be stated here.
 *
 * -15px is not a nice number and it is not ours to improve. It is what 483 blog
 * pages have looked like for years.
 * -------------------------------------------------------------------------- */
.ll-form--bs .ll-form__captcha {
	margin-bottom: -15px;
}

/* -----------------------------------------------------------------------------
 * An empty status line takes no space.
 *
 * Production's `.wpcf7-response-output` is `display: none` until there is
 * something to say. The engine's `.ll-form__message` is always in flow, and its
 * 16px height plus 12px top margin made every form 28px taller than production's.
 *
 * `:empty` rather than a class, so the element reappears the instant JavaScript
 * writes into it — the status still announces itself to screen readers through
 * `role="status"`, which is why the element stays in the DOM rather than being
 * conditionally rendered.
 * -------------------------------------------------------------------------- */
.ll-form--bs .ll-form__message:empty {
	display: none;
}

/*
 * THE WEBINAR FAMILY KEEPS THE DIV, and only loses its min-height.
 *
 * The first attempt at this un-scoped the `display: none` above, on the reasoning
 * that production's prototype renders the same div at height 0. Half right, and the
 * missing half cost 12px: measured on production, that div is `display: block`,
 * `height: 0` and `margin-top: 12px` — in flow, and the margin counts toward the
 * form's height. `display: none` took the 12px with it and left the form 12px
 * shorter than production's at all three widths.
 *
 * So: keep it in flow, drop only the `min-height: 1em` that made it 14px tall.
 * Measured after: form 553 on both hosts, submit at y=459 on both.
 *
 * Scoped to this family and not un-scoped again. `contact_lead`, `fitness_lead` and
 * `landing_lead` read ZERO at all three widths WITH the `display: none` in force,
 * so for them it is correct and a blanket rule would move three finished families
 * off their zero to fix one.
 *
 * It DOES cover the inline subscribe form on `/webinars`, which carries this same
 * modifier plus `ll-form--inline` — and that was checked rather than assumed,
 * because the harness has no reference for that page. Measured on production there:
 * the same div, `display: block`, `height: 0`, `margin-top: 4px`, in flow; ours was
 * `display: none` and the form 16px shorter. So the `:not(.ll-form--inline)` scope
 * I nearly added would have left a real difference on a page nothing measures.
 */
.ll-form--legacy-webinar .ll-form__message:empty {
	display: block;
	min-height: 0;
}

/* -----------------------------------------------------------------------------
 * cf7_contact_us's submit has no border on production.
 *
 * `.our-contact-form-section .wpcf7-submit { border: 0 }` — an inline rule from
 * template-blank.php, keyed on `wpcf7-submit`, which is the one class the engine
 * must never emit (general.js binds a click handler to it, and the side-channel
 * senders bind to `.wpcf7`). Ours keeps `.btn { border: 1px solid transparent }`
 * from blog-single.min.css, so the button measures 171.66x50 against production's
 * 169.66x48.
 *
 * Two pixels, and they are not cosmetic bookkeeping: they are 2 of the form's
 * height difference and 2 of the button's x offset at 390, where the submit is
 * right-aligned. Mirrors production's own scoping, so it cannot reach any other
 * family. The `background` from that same production rule is deliberately NOT
 * copied — the button colour is the settled #1690D3.
 * -------------------------------------------------------------------------- */
.our-contact-form-section .ll-form__submit {
	border: 0;
}

/*
 * And its submit wrapper CONTAINS the paragraph's margin, as production's does.
 *
 * On production `.form-btn` is a flex ITEM — the captcha and the submit block live
 * inside the row, which is `display: flex` — so it establishes an independent
 * formatting context and its inner `<p>`'s `margin-bottom: 24px` counts toward its
 * own height: measured 72px = button 48 + margin 24. The engine emits the submit
 * block OUTSIDE the wrapper chain, so `.form-btn` is a plain block child of
 * `<form>`, the margin collapses out through the form's bottom edge and is lost:
 * measured 50px, button only.
 *
 * `display: flow-root` is that containment named directly. The alternative was to
 * reorder the renderer's whole tail — captcha, decoy, hidden inputs and submit —
 * to sit inside the row the way production's do, which is a reordering of the
 * emission for 24px on one family of nine pages, with every other family's markup
 * as the blast radius. The containment is the effect that matters and it can be
 * stated in one declaration.
 */
.our-contact-form-section .form-btn {
	display: flow-root;
}

/* -----------------------------------------------------------------------------
 * cf7_whitepaper's left column keeps production's row pitch.
 *
 * Measured on both hosts, and the mechanism is a sibling relationship our markup
 * cannot have. Production's left `.col-lg-6` holds four `.field-input` DIVS as
 * siblings followed by its honeypot `<p>`, so:
 *
 *   fields 1-3  `:last-child` false, `:last-of-type` false  → 32px
 *   field 4     `:last-child` false (the `<p>`), `:last-of-type` TRUE
 *                                          → 32px above 576, 55px below it
 *
 * Ours wraps each field in its own `.ll-form__row` — which cannot be dropped: it
 * is what `llf-forms.js` finds with `closest('.ll-form__row, …')` to place an
 * error, and what the skin's `.ll-form__row--phone .iti` keys the country column
 * off. So every `.field-input` is the only child AND the only div of its parent,
 * matches both selectors, and takes 48px (≤992) or 55px (≤576) where production
 * takes 32.
 *
 * Measured pitch, prod vs ours: 68/68/68/59 vs 84/84/84/75 at 768, and
 * 68/68/68/82 vs 91/91/91/82 at 390 — the +16 and +23 per row that cascaded into
 * fifteen rows.
 *
 * Stated as values rather than restored as structure, and that is a deliberate
 * exception to this project's prefer-structure rule. Restoring the relationship
 * would need a sibling of a DIFFERENT TAG per position — a non-div after fields
 * 1-3 does not clear `:last-of-type`, a div after field 4 clears the very
 * `:last-of-type` production relies on there — so the structural route is four
 * empty nodes with two tags and a per-position rule, and it is easier to get
 * subtly wrong at one breakpoint than the two declarations below.
 *
 * The right column is untouched: production gives its lone textarea 48px at ≤992
 * and 55px at ≤576, which is what ours already takes.
 * -------------------------------------------------------------------------- */
/*
 * ⚠️ THE DOUBLED CLASS IS THE POINT, not a typo.
 *
 * The first version of these two rules was written without `.ll-form--bs`,
 * deployed, and had ZERO effect — the parity numbers came back byte-identical,
 * which is the tell: a wrong value moves the number, a rule that never applies
 * does not move it at all. Enumerated in the page afterwards, it was matching and
 * losing: the theme's
 * `section.contact-form .section-inner .field-input:last-child` (blog-single.min.css,
 * `max-width: 992px`) is (0,4,1) and mine was (0,4,0) — beaten on the element
 * component by that one `section`.
 *
 * Specificity compares (id, class, element) lexicographically, so one more class
 * wins outright: (0,5,0) > (0,4,1). Hence `.ll-form--bs` doubled onto the family
 * modifier — both are on the same element, both are ours, and neither can drift
 * apart from the other.
 *
 * Same arithmetic for the 576 exception, which must beat MY 32px rule as well as
 * the theme's `:last-of-type` one: (0,6,0).
 */
.ll-form--bs.ll-form--legacy-whitepaper .col-lg-6:first-child .field-input {
	margin-bottom: 32px;
}

@media screen and (max-width: 576px) {
	/* Below 576 production's LAST div in that column takes 55px — and ours is the
	 * last row, so this restores exactly that one and leaves the three above it. */
	.ll-form--bs.ll-form--legacy-whitepaper .col-lg-6:first-child .ll-form__row:last-child .field-input {
		margin-bottom: 55px;
	}
}

/* -----------------------------------------------------------------------------
 * cf7_case_study's upload block.
 *
 * Two terms that only make sense shipped together with the dnd class chain the
 * renderer now emits there (see the `'file'` branch): on their own they widen the
 * gap they are meant to close, because the dropzone's own 85px deficit was very
 * nearly cancelling them.
 *
 * The note: production's is an inline `font-size: 14px !important` in the CF7 form
 * body, measuring 43.4 / 43.4 / 65.1. Ours took 18px (16 below 992) from
 * `.landing-builder-wrapper … .tiles .tile .text` in landing-builder.min.css — a
 * six-class selector that beats `.ll-form__note`'s 13px on specificity — and
 * measured 55.8 / 49.6 / 74.4. Nothing short of `!important` wins that, which is
 * exactly what production does. Its margins are `0 0 1rem`, ours were `8px 0`.
 *
 * The gap below the dropzone: production's is the upload paragraph's own
 * `margin-bottom: 1rem`; ours was 8px, from `.ll-form__filelist`'s top margin
 * collapsing out through the dropzone's bottom edge.
 * -------------------------------------------------------------------------- */
.ll-form--legacy-case-study .ll-form__note {
	font-size: 14px !important;
	margin: 0 0 1rem;
}

/*
 * The uploader's inner box is a BLOCK on production, and ours was a flex row.
 *
 * `.codedropz-upload-inner` (dnd-upload-cf7.css) sets `text-align: center` and no
 * `display`, so the plugin's three children stack. `llf-forms.css
 * .ll-form__dropzone-ui { display: flex }` put them on one line: measured 34px
 * against production's 100, which is most of the 87px by which everything below
 * the upload sat too high.
 *
 * The browse control keeps its `<button>` — production's is an `<a>` and would be
 * 11px shorter, but an anchor with no href is not keyboard-focusable and not
 * announced as a control, which is not a trade worth eleven pixels. Instead it is
 * stripped back to the inline box an anchor occupies, and it now carries the
 * plugin's own `cd-upload-btn` class so the plugin's colour and decoration apply.
 */
.ll-form--legacy-case-study .ll-form__dropzone-ui {
	display: block;
}

.ll-form--legacy-case-study .ll-form__browse {
	display: inline;
	padding: 0;
	border: 0;
	background: none;
	font: inherit;
	color: inherit;
	cursor: pointer;
}

.ll-form--bs .ll-form__dropzone {
	margin-bottom: 1rem;
}

/* -----------------------------------------------------------------------------
 * The country column sizes to its content.
 *
 * On the case-study template a theme rule stretches `.iti__selected-flag` to the
 * full width of the field — measured at 620px inside a 622px input, on PRODUCTION
 * as well as here. intl-tel-input sets the input's `padding-left` from the flag's
 * width at init, so the result is a race: production happened to catch 436px and
 * the engine caught 626px, which leaves six pixels to type in.
 *
 * Production's number is not a target. A 620px flag column is a defect on both
 * hosts and the owner's rule is that defects do not travel across. `width: auto`
 * makes the column what it looks like everywhere else on the site, and the padding
 * the library computes from it becomes the ~88px every other family already has.
 * -------------------------------------------------------------------------- */
.ll-form--bs .ll-form__row--phone .iti__selected-flag {
	/*
	 * `max-content`, and it took two wrong guesses to get here.
	 *
	 * The library's own stylesheet makes this flag `position: absolute`, where
	 * `width: auto` would shrink it to its content. On this site something makes it
	 * `position: relative` — measured on production too — which turns it into a
	 * BLOCK-LEVEL flex container, and `auto` on one of those means "the full width
	 * of the parent". Releasing `right` changed nothing for the same reason: there
	 * is no absolute positioning to release.
	 *
	 * `max-content` is the one value that means "as wide as the flag and the dial
	 * code need" regardless of which positioning scheme the element ended up in.
	 */
	width: max-content;
	/*
	 * `nowrap` because the operator caught the flag column wrapping "+48" onto two
	 * lines. `max-width: 50%` was the cause: on a narrow field it clamps below the
	 * content, and a clamped box wraps. The clamp is gone — `max-content` already
	 * prevents the 620px runaway it was insuring against, and `nowrap` guarantees
	 * the dial code stays on one line whatever the column ends up being.
	 */
	white-space: nowrap;
	/*
	 * `min-width` because `max-content` alone is a race. The dial code is written
	 * into the flag by utils.js when it loads, so the column's content width depends
	 * on whether that has happened yet: measured 90px on case-study and 46px on
	 * contact-us in the same run, against production's 82-88px on both. A floor
	 * makes the column the size it has always been whichever way the race goes.
	 *
	 * `max-width` is the fuse at the other end: if a rule ever inflates the content
	 * again, the field keeps half its width to type in rather than going back to
	 * six pixels.
	 */
	min-width: 82px;
}

/* -----------------------------------------------------------------------------
 * An anchor for the error slot on the textarea field. Added 2026-09-09.
 *
 * The engine's error span now carries `wpcf7-not-valid-tip` as well as
 * `ll-form__error`, so the theme's own rules take it out of flow in the three
 * contact sections and a failed submit stops reflowing the form. Those rules hang
 * the span off `position: absolute; top: 100%`, which needs a positioned ancestor
 * — and the theme provides one for the ordinary case
 * (`… .section-inner .field-input { position: relative }`) but NOT for the
 * textarea: production's textarea override is
 * `.field-textarea .wpcf7-form-control-wrap .wpcf7-not-valid-tip
 *  { position: relative !important }`, keyed on a wrapper the engine does not
 * render.
 *
 * So without this line the textarea's error would stay absolute with no nearby
 * anchor and position itself against whatever came next up the tree — the
 * section, or the page — landing somewhere with no relation to the field it
 * describes. One line, and `position: relative` with no offsets moves nothing, so
 * it costs no geometry.
 *
 * Production ends up in flow here and the engine out of flow. That difference is
 * in the harmless direction: production's textarea error pushes the rest of the
 * form down, ours does not.
 * -------------------------------------------------------------------------- */
.ll-form .field-textarea {
	position: relative;
}

/* -----------------------------------------------------------------------------
 * The "Attach CV" pill: the half the theme's own rules cannot supply.
 *
 * The theme turns the drag-and-drop uploader into production's single grey pill
 * with nine rules gated on `.contact-form .field-file-input`, and the engine now
 * emits that wrapper and the plugin's class chain, so eight of the nine reach it.
 * The ninth does not:
 *
 *   .contact-form .field-file-input … a.cd-upload-btn { font-size: 0 }
 *
 * It is qualified `a.cd-upload-btn`, and the engine renders a `<button>` — on
 * purpose, and the renderer says so: "The browse control keeps its <button>
 * element and gains the plugin's class, so the plugin styles it and it stays
 * focusable." Meanwhile the rule that PRINTS the label,
 * `.contact-form .field-file-input .cd-upload-btn:before { content: "Attach CV" }`,
 * carries no element qualifier and does reach us.
 *
 * So without this line the control shows "Attach CV" printed on top of "Browse
 * Files" — both at once, which is worse than the plain file input it replaced.
 * Changing the element to an anchor to match the selector would trade keyboard
 * access for a font-size.
 *
 * The accessible name comes from `aria-label`, declared per definition
 * (`structure['browse_aria']`). Production's anchor has no name at all — hiding
 * text with `font-size: 0` removes it — so this reproduces the look and not the
 * defect.
 * -------------------------------------------------------------------------- */
.contact-form .field-file-input .codedropz-upload-inner .codedropz-btn-wrap button.cd-upload-btn {
	font-size: 0;
	/*
	 * Chrome only — NOT size, NOT position.
	 *
	 * A `<button>` brings a border and a background; production's control is an
	 * `<a>` and brings neither. At `font-size: 0` the element is 16x6, so its
	 * 2px border painted a small grey tick to the left of the pill — visible in
	 * the screenshot, invisible to every measurement I took.
	 *
	 * Deliberately no `width`/`position` here: those were tried today, moved the
	 * pill 192px off production's place, and are reverted. Removing chrome has no
	 * geometric side effect at this font-size.
	 */
	border: 0;
	background: none;
	padding: 0;
}

/*
 * NO position, width or border here — and the absence is the fix.
 *
 * Today I gave this button `position: relative` plus a 220px box, to stop the
 * "Attach CV" pseudo-element landing on the "Drag & Drop Files Here" text. It
 * did stop that, and it moved the pill 192px right and 90px down of production's
 * (measured), because the pill sizes and places itself against its containing
 * block and production's containing block is `.field-file-input`, not the button.
 *
 * The overlap was never a CSS problem. It was our markup showing a title
 * production deletes. With the title emitted as `<h3>` the theme's own rule hides
 * it, there is nothing left to overlap, and the pill sits where production puts
 * it with no help from this file. A compensation for the wrong markup is worse
 * than no compensation: it hides the cause and moves the symptom.
 */


/* -----------------------------------------------------------------------------
 * The phone's flag must overlay the input, not push it to the next line.
 *
 * Reported 2026-09-14 on cf7_case_study: "надпись Phone Number* съехала, ниже
 * кода страны". Measured: the flag container's top is 9170 and the input's 9199 —
 * two lines, 29px apart. On /about-us the same widget measures the same top for
 * both, i.e. one line, which is what intl-tel-input does when its container is
 * `position: absolute` (its own stylesheet says so).
 *
 * What overrides it is not a form rule at all:
 *
 *   .landing-builder-wrapper .landing-builder .builder-part.part-grid_tiles
 *   .tiles .tile .text *        <- landing-builder.min.css
 *
 * — a blanket `*` belonging to a tile component, which on this template encloses
 * the form and re-declares `position` on every descendant. Six classes plus the
 * universal selector: no selector this file could reasonably write outranks it,
 * and lengthening ours to match would be a specificity race decided by whoever
 * edits last.
 *
 * `!important` is the honest instrument here, and it is narrow: it restores the
 * VENDOR'S OWN value for the vendor's own element, inside engine forms only. It
 * changes nothing where the flag is already absolute (measured on /about-us).
 * -------------------------------------------------------------------------- */
.ll-form .iti__flag-container,
.ll-form--bs .iti__flag-container {
	position: absolute !important;
}

/* -----------------------------------------------------------------------------
 * Long country names are not cut off in the dropdown.
 *
 * Reported 2026-09-14: "країни з великими назвами відображаються не повністю".
 * Measured: the list's content box is 428px while its widest row needs 513px, so
 * 6 of 246 rows lose their tail — worst case 75px, on "Saint Pierre and Miquelon
 * (Saint-Pierre-et-Miquelon)". The cap is the theme's own
 * `.iti__country-list { max-width: 430px }` (css/general.css:377); the vendor
 * declares no width at all and the list shrink-to-fits, so it cannot clip by
 * itself.
 *
 * Only from 768px up. Measured with the cap removed, the list becomes 515px wide
 * and ends at x=691 against a 768px viewport — it fits; at 600 it overruns by
 * 7px and at 520 by 47px, where `body { overflow-x: hidden }` would clip it
 * WORSE than the 75px this fixes. Below 500px the vendor already wraps names onto
 * a second line instead of cutting them.
 *
 * Placed here rather than in general.css on purpose: that rule is inlined into
 * ~21 PurgeCSS bundles, and editing the source without rebuilding all of them
 * would fix nothing while looking fixed. This file is never bundled (see the
 * header) and loads last, so it reaches every engine page with no rebuild — and
 * touches only engine pages, which is the scope this branch owns.
 * -------------------------------------------------------------------------- */
@media (min-width: 768px) {
	.ll-form .iti__country-list,
	.ll-form--bs .iti__country-list {
		max-width: none;
	}
}

/* -----------------------------------------------------------------------------
 * The native file input must not take up space.
 *
 * Measured on `/careers/<position>?apply` after the markup was brought back to
 * production's: `.field-file-input` was still 105px against production's 69, and
 * the difference was the `<input type="file">` itself — box 220x45 at the top
 * left of the wrapper, painting the grey sliver the tester can see above the
 * pill.
 *
 * It carries `d-none`, which does nothing here, and the rule that hides it for
 * the block-rendered families is scoped to those blocks
 * (`.block-ll-hero-form-dark-split .ll-form__file`), so the bootstrap families
 * never had one. Production hides it with the upload plugin's own CSS, which our
 * input does not match because it does not carry the plugin's class.
 *
 * Taken out of flow rather than `display: none`: the control must stay reachable
 * for a click and for assistive technology, which is what the 1px/opacity idiom
 * is for — and it is the same idiom the block stylesheets already use here.
 * -------------------------------------------------------------------------- */
.ll-form--bs .ll-form__file {
	position: absolute;
	width: 1px;
	height: 1px;
	opacity: 0;
	overflow: hidden;
}

/* -----------------------------------------------------------------------------
 * The file list must clear the "Attach CV" pill.
 *
 * Reported 2026-09-14 with a screenshot: after attaching, the pill sits on top of
 * the file name. Measured — 5px of overlap, file row top 716 against a pill whose
 * painted box runs lower, because the pill is an ABSOLUTE pseudo-element on a
 * zero-sized button and therefore occupies no space in flow at all. The list is
 * laid out as if the control were 0px tall, so it starts underneath it.
 *
 * Room is given to the LIST, not taken from the pill: moving or sizing the pill
 * is what put it 192px off production's place earlier today, and it is the one
 * thing here that must keep matching production exactly.
 *
 * Only where the pill exists — `.contact-form .field-file-input` is the wrapper
 * that carries the theme's nine "Attach CV" rules. `cf7_case_study` uploads
 * through the same list with no pill above it and must not gain a gap.
 *
 * `:not(:empty)` so the empty state is untouched: the server renders the <ul>
 * with no whitespace and the script empties it with innerHTML = ''.
 * -------------------------------------------------------------------------- */
.contact-form .field-file-input .ll-form__filelist:not(:empty) {
	margin-top: 26px;
}

/* -----------------------------------------------------------------------------
 * The consent error printed at the edge of the form. Added 2026-09-15.
 *
 * MEASURED FIRST, and the first explanation was wrong, so it is written down.
 * The guess was "no positioned ancestor, so it escapes to the section" — the
 * story behind the textarea anchor above. Not this time: on the stand the
 * error's `offsetParent` IS `.ll-form__consent`, so the anchor was already there.
 *
 * The real cause is simpler. The theme hangs the tip off
 * `position: absolute; top: 100%; left: 0`
 * (`section.contact-form .section-inner .wpcf7-not-valid-tip`), and an absolute
 * box with `right: auto` is shrink-to-fit: 210px wide, pinned to the left of a
 * row whose text is centred. `text-align: center` was already inherited and had
 * nothing to centre it in. So the message sat under the first column while the
 * checkbox it describes sat in the middle — reported with a screenshot.
 *
 * `right: 0` was the obvious repair and it IS centred — and it lands on top of
 * the Turnstile frame, because the consent row has 25px of clearance below it
 * and the tip needs 23. Measured, then seen: the fix that satisfied the numbers
 * put red text through the captcha's top border.
 *
 * So the tip goes back INTO FLOW for this row, which is the same escape the
 * theme itself takes for the one other field where `top: 100%` has nowhere to
 * go (`.field-textarea … { position: relative !important; top: unset !important }`).
 * In flow it is a block inside a centred label: centred by inheritance, sized by
 * the row, and it pushes the captcha down by its own height instead of over it.
 *
 * `:not(:empty)` because the span is rendered on every load and filled only when
 * a submit fails — without it every consent row would carry an empty line.
 * -------------------------------------------------------------------------- */
.ll-form .ll-form__consent .ll-form__error:not(:empty) {
	position: relative;
	top: auto;
	left: auto;
	right: auto;
	display: block;
	margin-top: 5px;
}

/* -----------------------------------------------------------------------------
 * The form-level message follows the button it belongs to. Added 2026-09-15.
 *
 * Production has no such element at all: `.wpcf7-response-output` is
 * `display: none !important` in both the critical and the main bundle, because
 * CF7's summary duplicates the per-field tips. Ours is not a duplicate — it is
 * what tells a visitor WHY a click did nothing when the failing field is off
 * screen — so it stays. But the div is full-width and its text is left-aligned,
 * so under a centred button it read as a stray line at the edge of the section
 * rather than as this form's answer (same screenshot as above).
 *
 * Centred only on the families whose submit row is centred, which is what
 * `--bs` selects; the rest keep their own alignment.
 * -------------------------------------------------------------------------- */
.ll-form--bs .ll-form__message {
	text-align: center;
}

/* -----------------------------------------------------------------------------
 * Three families where the -15px captcha margin lands as a real overlap.
 * Measured and corrected 2026-09-15, after testers reported it.
 *
 * THIS IS A CORRECTION OF MY OWN EARLIER CHANGE, and the reasoning is written
 * down because the first pass got it backwards.
 *
 * `.ll-form--bs .ll-form__captcha { margin-bottom: -15px }` above reproduces
 * production's `.cf7-cf-turnstile` value, and for most families it is right:
 * measured on the stand against production at 1440, `cf7_article` 33/33,
 * `contact_lead` 24/24, `fitness_lead` 20/20, `landing_lead` 20/20 — identical.
 *
 * In three families nothing offsets it, and the submit button ends up FIFTEEN
 * PIXELS ABOVE the captcha's bottom edge — an overlap, at every width, not only
 * at the 2560px where it was spotted:
 *
 *   form                stand    production
 *   cf7_solutions_alt    -15         20
 *   cf7_contact_us       -15          9
 *   cf7_case_study       -15      (no captcha on production)
 *
 * So the value is restored per family to what production actually measures.
 * `cf7_case_study` has no production reference — that page carries no captcha at
 * all — so 20px is a CHOICE, not a measurement: it is what the other families on
 * this site use, and it is stated as a choice so nobody later mistakes it for a
 * number taken from somewhere.
 *
 * Scoped per family on purpose. The second form on the fitness-solutions page is
 * `cf7_standard` (`ll-form--legacy-standard`), measured at 33px and correct — a
 * rule written against the PAGE rather than the family would have pushed it to
 * 68 and traded one defect for another.
 * -------------------------------------------------------------------------- */
.ll-form--legacy-solutions-alt .ll-form__captcha {
	margin-bottom: 20px;
}

.ll-form--legacy-contact-us .ll-form__captcha {
	margin-bottom: 9px;
}

.ll-form--legacy-case-study .ll-form__captcha {
	margin-bottom: 20px;
}

/*
 * A FOURTH family, found by a sweep of my own on 2026-09-15 and not by a tester —
 * `cf7_recruiting`, the job-application form, measured at the same -15px. Testers
 * had marked it green: the overlap is fifteen pixels and it sits under a captcha,
 * which is exactly the kind of thing a human scanning eighteen forms does not see.
 *
 * It is here rather than in the block above because the first sweep MISSED it: I
 * measured fourteen pages and the careers form was not among them. The list came
 * from the test plan's table, which is written for people opening pages, not for a
 * script enumerating families. Worth remembering the next time a sweep is called
 * complete.
 *
 * 20px is a choice again, not a measurement — production renders no captcha on
 * this form either, so there is nothing to copy.
 */
.ll-form--legacy-recruiting .ll-form__captcha {
	margin-bottom: 20px;
}

/* -----------------------------------------------------------------------------
 * The upload counter sat OUTSIDE its own drop zone. Reported 2026-09-15
 * («Цифра 0 чуть на форму залезла»), measured, and corrected here.
 *
 * WHAT IT ACTUALLY DID. On the case-study family the counter is
 * `position: relative; left: -5px; display: inline` — the drag-and-drop
 * plugin's own value, meant for a layout this page does not have. Measured
 * against its handler at 1440: 3px PAST the left edge and 37px BELOW the
 * bottom. The digit was outside the box on two sides, which is exactly what a
 * tester sees as "the 0 has climbed onto the form".
 *
 * WHY ONLY HERE. Production and the newer block skins already place it
 * absolutely inside, and measurement says so: production insets it 17px from
 * the right edge (`/contact-us/` and `/solutions/fitness-software-solutions/`),
 * and `contact_lead` on the stand matches that. This family gets the plugin's
 * default because the page loads no rule that overrides it.
 *
 * `!important` is not decoration. Without it `position` loses to the plugin's
 * own rule and only `display` applies — which stretched the counter to the full
 * width of the zone. Measured that way round first.
 *
 * SCOPED TO THIS FAMILY ON PURPOSE. The same rule written against `.ll-form--bs`
 * also reaches the recruiting form, where the counter currently measures ZERO
 * width — it draws nothing — and the rule would make it appear. That form has
 * already been signed off by testers; a counter nobody has seen is not something
 * to introduce in the middle of their run. Its placement is wrong there too
 * (measured 662px above its own zone) and is recorded separately rather than
 * fixed blind.
 * -------------------------------------------------------------------------- */
.ll-form--legacy-case-study .codedropz-upload-handler {
	position: relative;
}

.ll-form--legacy-case-study .ll-form__dropzone-count {
	position: absolute !important;
	top: auto !important;
	left: auto !important;
	right: 16px !important;
	bottom: 8px !important;
	display: block !important;
	width: auto !important;
	font-variant-numeric: tabular-nums;
}