/* ========================================
   Form fields

   .bc-field is the one canonical text-field look -- border, radius, padding,
   height, font-size -- for any input, select or textarea that is not part of
   WooCommerce's own .form-row (checkout, My Account, addresses already have
   their own rule in woocommerce-custom.css, reading the same tokens below
   instead of its old hardcoded numbers, so the two cannot drift).

   Contact Form 7's default markup and the MX Contract Withdrawal plugin's own
   form template cannot carry the class -- neither renders through a theme
   template -- so they read the same --bc-field-* custom properties on their
   own selectors instead, the same mechanism .btn's own --bc-btn-* tokens
   already use for a button that cannot carry .btn either.

   Values were picked to match WooCommerce Blocks' checkout fields -- the one
   form on the site nobody hand-styled, and the one this was measured against
   as the reference: a 1px border (not the 2px .form-row used, which read
   heavy), --radius-s, and 16px text (already the --text-ui token).
======================================== */

:root {
	--bc-field-height: var(--space-12); /* 48px */
	--bc-field-radius: var(--radius-s); /* 4px */
	--bc-field-border-width: var(--border-width); /* 1px */
	--bc-field-border-color: var(--color-border-strong);
	--bc-field-pad-inline: var(--space-3); /* 12px */
	--bc-field-pad-block: var(--space-2); /* 8px */
	--bc-field-font-size: var(--text-ui); /* 16px */
}

.bc-field,
.wpcf7-form input[type="text"],
.wpcf7-form input[type="email"],
.wpcf7-form input[type="tel"],
.wpcf7-form input[type="url"],
.wpcf7-form input[type="number"],
.wpcf7-form textarea,
.wpcf7-form select,
.mx-cw-form .mx-cw-field input[type="text"],
.mx-cw-form .mx-cw-field input[type="email"],
.mx-cw-form .mx-cw-field input[type="tel"],
.mx-cw-form .mx-cw-field select,
.mx-cw-form .mx-cw-field textarea {
	display: block;
	box-sizing: border-box;
	width: 100%;
	height: var(--bc-field-height);
	padding-block: var(--bc-field-pad-block);
	padding-inline: var(--bc-field-pad-inline);
	border: var(--bc-field-border-width) solid var(--bc-field-border-color);
	border-radius: var(--bc-field-radius);
	background-color: var(--color-surface-raised);
	color: var(--color-text);
	font-family: inherit;
	font-size: var(--bc-field-font-size);
}

.mx-cw-form .mx-cw-field input[type="text"],
.mx-cw-form .mx-cw-field input[type="email"],
.mx-cw-form .mx-cw-field input[type="tel"],
.mx-cw-form .mx-cw-field select,
.mx-cw-form .mx-cw-field textarea {
	font-size: 16px;
}

.mx-cw-form .mx-cw-button {
	font-size: 17px;
}

textarea.bc-field,
.wpcf7-form textarea,
.mx-cw-form .mx-cw-field textarea {
	height: auto;
	min-height: 8em;
	padding-block: var(--space-3);
	resize: vertical;
}

.bc-field:focus,
.wpcf7-form input:focus,
.wpcf7-form textarea:focus,
.wpcf7-form select:focus {
	box-shadow: 0 0 3px 0 var(--color-focus);
	outline: 2px solid var(--color-focus);
	outline-offset: 2px;
}

.bc-field-label,
.wpcf7-form label {
	display: block;
	margin-bottom: var(--space-2);
	font-weight: var(--font-mild);
}

/* ========================================
   Contact Form 7

   CF7's default template wraps each field inside its own <label>, and that is
   the reason this form was hard to style rather than a symptom of it. The
   theme's reset gives inputs `font: inherit`, so a bold label made the input's
   own text bold too, and there was no element to hang a field's layout on: the
   label, the control and the validation tip were three inline things in a row.

   The template this expects puts the label beside the field inside a
   .bc-form__field block, which is the same shape every other form on the site
   already has. It lives in the CF7 form editor, not here.

   The field selectors at the top of this file still list bare input/textarea/
   select alongside .bc-field, so a field added later without the class still
   looks right.
======================================== */

.wpcf7-form {
	display: flex;
	flex-direction: column;
	gap: var(--space-5);
	max-width: 40rem;
}

.wpcf7-form .bc-form__field {
	margin: 0;
}

.wpcf7-form .wpcf7-form-control-wrap {
	display: block;
}

/* "(neobvezno)" and the like: part of the label, not another bold word in it. */
.bc-field-label__optional {
	color: var(--color-text-muted);
	font-weight: normal;
}

/* ========================================
   Contact Form 7 - validation

   CF7's own stylesheet loads after the theme's, so every rule from here down
   is written to beat it on specificity rather than on source order. That is
   also why the response-output rules carry .wpcf7 form.wpcf7-form: CF7 styles
   the same element as .wpcf7 form.invalid .wpcf7-response-output, and a tie
   would go to whichever sheet printed last.
======================================== */

.wpcf7-form .wpcf7-not-valid-tip {
	display: block;
	margin-top: var(--space-1);
	color: var(--color-danger);
	font-size: var(--text-body-s);
}

/*
 * .bc-field.wpcf7-not-valid is two classes and beats the field rule at the top
 * of this file, which is one class plus an attribute selector. The bare
 * input/textarea/select fallbacks tie with it and win on source order, being
 * later in the same file.
 */
.wpcf7-form .bc-field.wpcf7-not-valid,
.wpcf7-form input.wpcf7-not-valid,
.wpcf7-form textarea.wpcf7-not-valid,
.wpcf7-form select.wpcf7-not-valid {
	border-color: var(--color-danger);
}

.wpcf7 form.wpcf7-form .wpcf7-response-output {
	margin: 0;
	padding: var(--space-3) var(--space-4);
	border: var(--border-width) solid var(--color-border-strong);
	border-radius: var(--radius-s);
	font-size: var(--text-body-s);
}

.wpcf7 form.wpcf7-form.invalid .wpcf7-response-output,
.wpcf7 form.wpcf7-form.unaccepted .wpcf7-response-output,
.wpcf7 form.wpcf7-form.payment-required .wpcf7-response-output,
.wpcf7 form.wpcf7-form.failed .wpcf7-response-output,
.wpcf7 form.wpcf7-form.aborted .wpcf7-response-output {
	border-color: var(--color-danger);
	color: var(--color-danger);
}

.wpcf7 form.wpcf7-form.sent .wpcf7-response-output {
	border-color: var(--color-action);
}

/* ========================================
   Contact Form 7 - submit and loader

   CF7 renders its spinner as a sibling of the submit input, so it cannot be
   put inside the button in markup -- an <input> has no children. Instead
   .bc-form__actions shrinks to the button's own width and becomes the
   positioning context, which drops the absolutely positioned spinner in the
   middle of the button rather than trailing after it as a stray grey dot.

   The ring is the add-to-cart loader's shape on purpose (the 1.2em circle in
   woocommerce-custom.css, .woocommerce .product .button.loading::after), so a
   form submit and an add-to-cart read as the same site. It keeps its own
   @keyframes rather than borrowing bc-atc-spin from the WooCommerce fork: this
   component should not stop animating if that file is ever sliced differently.
======================================== */

.wpcf7-form .bc-form__actions {
	position: relative;
	align-self: flex-start;
	margin: 0;
}

.wpcf7 form.wpcf7-form .wpcf7-spinner {
	position: absolute;
	top: 50%;
	left: 50%;
	width: 1.2em;
	height: 1.2em;
	margin: -0.6em 0 0 -0.6em;
	padding: 0;
	box-sizing: border-box;
	border: 2px solid var(--color-action-text);
	border-bottom-color: transparent;
	border-left-color: transparent;
	border-radius: 50%;
	background: none;
	opacity: 1;
	animation: bc-form-spin .7s linear infinite; /* the add-to-cart loader's rate; --duration-* are UI transitions, not spin cycles */
}

/* CF7 draws a pulsing dot inside its spinner; the ring replaces it. */
.wpcf7 form.wpcf7-form .wpcf7-spinner::before {
	content: none;
}

/*
 * The label goes invisible while the spinner runs, the way the add-to-cart
 * button's own span does, so the two never overlap. The ring is painted in
 * --color-action-text rather than currentColor precisely so it survives this.
 */
.wpcf7-form.submitting .wpcf7-submit {
	color: transparent;
}

@keyframes bc-form-spin {

	to {
		transform: rotate(360deg);
	}
}

/* ========================================
   MX Contract Withdrawal - colour scheme

   The plugin's stylesheet loads after the theme's and its colour rules are
   scoped to .mx-cw-public.mx-cw-color-scheme-custom, which outranks anything
   written here, so the field borders stayed the plugin's pale #dbe3ec no
   matter what this file said about them. The geometry above still applied --
   height, padding, radius, font-size -- which is why the form looked right in
   every respect except its washed-out borders.

   Rather than fight that, the theme feeds the plugin's own theming variables.
   The plugin reads --mx-cw-border-strong for input/select/textarea borders and
   --mx-cw-border for cards, fieldsets and tables: two separate variables that
   its settings screen collapses into a single "border" colour, which is why
   the card outline and the field borders were the same washed-out blue.
   Splitting them here is what makes the fields read like every other field on
   the site while the card keeps a quiet outline.

   !important is needed only because the plugin prints these as an inline style
   attribute on .mx-cw-public, generated from its mx_cw_settings option, and an
   inline declaration beats any normal author rule regardless of specificity.
   It is not a specificity workaround: nothing here competes with a plugin
   selector, it only changes what those selectors resolve to.

   The alternative was editing frontend_custom_* in mx_cw_settings, but those
   are stored hex values -- frozen copies that would drift the moment a token
   changes -- and with only one "border" slot they could not have separated the
   card from the fields at all.

   The plugin also paints its own focus ring off --mx-cw-focus at a specificity
   this file cannot reach, so the focus rule above deliberately does not list
   the MX selectors: a second outline on top produced two rings. Mapping
   --mx-cw-focus onto --color-focus makes it the theme's focus colour, drawn by
   the plugin.
======================================== */

.mx-cw-public {
	--mx-cw-background: var(--color-surface) !important;
	--mx-cw-surface: var(--color-surface-muted) !important;
	--mx-cw-surface-raised: var(--color-surface-raised) !important;
	--mx-cw-text: var(--color-text) !important;
	--mx-cw-text-strong: var(--color-text) !important;
	--mx-cw-text-muted: var(--color-text-muted) !important;
	--mx-cw-border: var(--color-border-subtle) !important;
	--mx-cw-border-strong: var(--bc-field-border-color) !important;
	--mx-cw-input-background: var(--color-surface-raised) !important;
	--mx-cw-primary: var(--color-action) !important;
	--mx-cw-primary-text: var(--color-action-text) !important;
	--mx-cw-secondary: var(--color-surface-raised) !important;
	--mx-cw-secondary-text: var(--color-text) !important;
	--mx-cw-link: var(--color-link) !important;
	--mx-cw-focus: var(--color-focus) !important;
}

/*
 * The field error is the one piece of the form that sits outside the plugin's
 * colour-scheme variables -- a hardcoded #b91c1c with no --mx-cw-* rule to
 * feed -- so it is the only thing here that needs a selector rather than a
 * value. The field description looks like it would need one too and does not:
 * it reads --mx-cw-text-muted, which the block above already answers.
 */
.mx-cw-public .mx-cw-field-error {
	color: var(--color-danger);
}

/* ========================================
   MX Contract Withdrawal - type and layout

   The type scale is em-based against a 19px body: --text-ui is 0.842105em,
   which is 16px only while its parent is 19px. The plugin sets its own
   font-size: 16px on .mx-cw-form, so every em token inside resolves against
   16px instead and --text-ui lands at 13.5px. The fields and the buttons both
   read visibly small, and picking a different token does not help, because
   the whole --text-body-* scale carries the same dependency.

   Pinning the two component tokens in rem fixes every field and every button
   in the form at once: a rem resolves against the root, so nothing the plugin
   does to its own font-size can move it. 1rem is the same 16px --text-ui is
   meant to be, not a new value, and 0.9375rem is --text-meta's 15px.

   This is the trap CLAUDE.md already records for the WooCommerce notice
   button, where it was solved with a literal on one selector. Expect it in any
   third-party block that sets a font-size of its own: the fix is a rem, not a
   different token.
======================================== */

.mx-cw-public {
	--bc-field-font-size: 1rem; /* 16px */
	--bc-btn-font-size: 1rem; /* 16px */
}

.mx-cw-form .mx-cw-button-small {
	--bc-btn-font-size: 0.9375rem; /* 15px */
}

/*
 * .mx-cw-actions is the plugin's own flex row, and .btn's default flex: 1 1 0
 * makes a lone button in it stretch to the full width of the card. The button
 * sizes to its label instead, floored by --bc-btn-min-width the same way every
 * other button on the site is.
 */
.mx-cw-form .mx-cw-button {
	flex: 0 0 auto;
}