/* Gravity Forms — brand styling to match the site (Contact, etc.).
 *
 * MODERN MARKUP since 2026-08-18. The contact form previously rendered in
 * Gravity's legacy markup, not by choice: the form predates GF 2.5 and carries
 * no `markupVersion`, which GF treats as legacy. The global "enable legacy"
 * option was already off. `content/_rebuilt/gravity-markup.php` sets version 2
 * so every environment agrees.
 *
 * What that bought: the validation block below went from eighteen selectors to
 * six, and the name and email fields now render as real <fieldset>/<legend>
 * groups rather than a <label> over a bag of inputs.
 *
 * WHAT IT DID NOT BUY, and this is a correction to what this file used to say.
 * The old comment here claimed "the modern theme derives every failure state
 * from one custom property, --gf-color-danger", and used that to explain why an
 * override was dead code. The dead-code part was right; the reason was wrong.
 * `--gf-color-danger` is defined in `gravity-forms-theme-framework.min.css`,
 * which this form does not load — the wrapper is `gform-theme--no-framework`
 * and the two stylesheets that do load contain **zero** `--gf-` properties.
 * Checked by grepping the shipped CSS rather than by reading the docs.
 *
 * EVERY SELECTOR HERE CARRIES `.gravity-theme`, and it is not decoration.
 * Gravity writes its own rules as `.gform_wrapper.gravity-theme .x`, so a
 * plainer `.gform_wrapper .x` loses on specificity and does nothing at all.
 * Measured rather than assumed: before this qualifier, labels rendered 16px/700
 * against the 13px/400 written here, field spacing collapsed to 0, input
 * padding fell to 8px, and five of six validation colours stayed Gravity's red.
 * Matching their specificity is enough — no `!important` — because this sheet
 * is enqueued after theirs (verified: theirs at index 16 and 18, ours at 22).
 * Keep new rules qualified the same way; a mixed file re-invites the bug.
 *
 * Staying on `no-framework` is deliberate. Loading the framework would bring
 * GF's whole design system — its own palette, spacing and type scale — to fight
 * the one this site already has. The custom-property API is not worth that.
 */
.gform_wrapper.gravity-theme {
	max-width: 560px;
	margin: 8px auto;
}
.gform_wrapper.gravity-theme form {
	padding: 28px;
	border: 1px solid color-mix( in srgb, var( --wp--preset--color--primary ) 25%, transparent );
	border-radius: 2px;
	background: color-mix( in srgb, #ffffff 45%, var( --wp--preset--color--background ) );
}
.gform_wrapper.gravity-theme .gfield {
	margin-bottom: 16px;
}

/* Labels. Colour and weight are shared; size is not.
 *
 * `.gform-field-label` is here as well as `.gfield_label` because modern markup
 * gives sub-labels only the former — without it they fall through to Gravity's
 * default and read a size and colour apart from every other label on the form.
 *
 * Nothing targets `.gform-field-label__text`, the span Gravity puts inside each
 * label: it has no size of its own and inherits from the label, so styling the
 * label reaches it. One less selector to keep true. */
.gform_wrapper.gravity-theme .gfield_label,
.gform_wrapper.gravity-theme .gform-field-label,
.gform_wrapper.gravity-theme .ginput_complex label {
	color: var( --wp--preset--color--muted );
	font-weight: 400;
}

/* Main field labels — "Your Name", "Your message" (owner, 2026-08-18: 15px). */
.gform_wrapper.gravity-theme .gfield_label,
.gform_wrapper.gravity-theme legend.gfield_label {
	font-size: 15px;
}

/* Sub-labels — "First", "Last", "Enter Email" — stay at 13px. They name a part
   of a field rather than a field, and should read as subordinate to the label
   above them. `.ginput_complex label` is (0,3,1), which is also what keeps it
   above Gravity's own sub-label sizing. */
.gform_wrapper.gravity-theme .ginput_complex label,
.gform_wrapper.gravity-theme .gform-field-label--type-sub {
	font-size: 13px;
}
.gform_wrapper.gravity-theme input[type="text"],
.gform_wrapper.gravity-theme input[type="email"],
.gform_wrapper.gravity-theme input[type="url"],
.gform_wrapper.gravity-theme input[type="tel"],
.gform_wrapper.gravity-theme select,
.gform_wrapper.gravity-theme textarea {
	font: inherit;
	width: 100%;
	padding: 12px 14px;
	border: 1px solid color-mix( in srgb, var( --wp--preset--color--primary ) 35%, transparent );
	border-radius: 2px;
	background: transparent;
	color: var( --wp--preset--color--foreground );
}
.gform_wrapper.gravity-theme textarea {
	min-height: 140px;
}
.gform_wrapper.gravity-theme input::placeholder,
.gform_wrapper.gravity-theme textarea::placeholder {
	color: color-mix( in srgb, var( --wp--preset--color--muted ) 70%, transparent );
}

/* Modern renders submit as <button class="gform_button">; legacy used
   input[type=submit]. Both are matched so this survives either. */
.gform_wrapper.gravity-theme .gform_footer input[type="submit"],
.gform_wrapper.gravity-theme .gform_footer button,
.gform_wrapper.gravity-theme .gform-footer button {
	font: inherit;
	cursor: pointer;
	padding: 12px 22px;
	border: 1px solid var( --wp--preset--color--primary );
	border-radius: 2px;
	background: transparent;
	color: var( --wp--preset--color--primary );
	text-transform: uppercase;
	letter-spacing: 0.08em;
	transition: all 0.2s ease-out;
}
.gform_wrapper.gravity-theme .gform_footer input[type="submit"]:hover,
.gform_wrapper.gravity-theme .gform_footer button:hover,
.gform_wrapper.gravity-theme .gform-footer button:hover {
	background: var( --wp--preset--color--primary );
	color: var( --wp--preset--color--background );
}
.gform_wrapper.gravity-theme .gfield_required {
	color: var( --wp--preset--color--primary );
}
.gform_confirmation_message {
	text-align: center;
	padding: 24px;
	color: var( --wp--preset--color--foreground );
}

/* ── Validation ──────────────────────────────────────────────────────────
 *
 * Gravity hardcodes its own red. It is close enough to the site's `alert`
 * (#7A2318) that nobody would call it wrong — but "close enough" is how a
 * palette stops being one, and a red on the contact page a shade off the red at
 * the checkout reads as sloppy without ever being noticed directly.
 *
 * Six selectors, taken from the markup an actual failed submission produces
 * rather than from documentation:
 *
 *   .gform_wrapper.gform_validation_error   set on the wrapper
 *   .gform_validation_errors                the summary box at the top
 *   .gfield.gfield_error                    the failed field
 *   [aria-invalid="true"]                   the failed input
 *   .gfield_validation_message              the message under the field
 *   .gform-icon--circle-error               the icon in the summary
 *
 * Colour and border only. Nothing here touches `display` — Gravity reveals
 * messages by inserting them, and a `display` rule here is how a reveal gets
 * silently disabled (see the `.mepr-hidden` note in memberpress.css). The wash
 * on a failed field is kept as a tint rather than removed, so the field is
 * findable by scanning and not only by reading.
 */
/* `.gravity-theme` is on every selector below on purpose. Gravity writes its
   own rules as `.gform_wrapper.gravity-theme .x` — two classes on the wrapper —
   so a plainer `.gform_wrapper.gravity-theme .x` loses on specificity and the override
   silently does nothing. Measured, not guessed: the first version of this block
   left five of six states rendering Gravity's #C02B0A instead of the site's
   #7A2318, and only the icon (which Gravity styles less specifically) came out
   right.

   Matching their specificity is enough — no `!important` required — because
   this stylesheet is enqueued after theirs. Verified in the browser: theirs at
   sheet index 16 and 18, ours at 22. If that order ever changes these rules go
   quiet again, which is the tradeoff for not reaching for the flag. */
.gform_wrapper.gravity-theme .gfield_error .gfield_label,
.gform_wrapper.gravity-theme .gfield_error legend,
.gform_wrapper.gravity-theme .gfield_error label,
.gform_wrapper.gravity-theme .gfield_validation_message,
.gform_wrapper.gravity-theme .gform_validation_errors > h2,
.gform_wrapper.gravity-theme .gform_validation_errors > ol a,
.gform_wrapper.gravity-theme .gform-icon--circle-error {
	color: var( --wp--preset--color--alert );
}

.gform_wrapper.gravity-theme .gform_validation_errors {
	border: 1px solid color-mix( in srgb, var( --wp--preset--color--alert ) 35%, transparent );
	background: color-mix( in srgb, var( --wp--preset--color--alert ) 5%, transparent );
	box-shadow: none;
}

/* The failed-field marker — border and a 5% wash, matching what invalid inputs
   already get at the checkout in memberpress.css. The same state should not
   look like two different ideas across two forms. */
.gform_wrapper.gravity-theme .gfield.gfield_error {
	background-color: color-mix( in srgb, var( --wp--preset--color--alert ) 5%, transparent );
	border-top: 1px solid color-mix( in srgb, var( --wp--preset--color--alert ) 30%, transparent );
	border-bottom: 1px solid color-mix( in srgb, var( --wp--preset--color--alert ) 30%, transparent );
}
.gform_wrapper.gravity-theme .gfield_error [aria-invalid="true"],
.gform_wrapper.gravity-theme [aria-invalid="true"] {
	border: 1px solid var( --wp--preset--color--alert );
}