/*
 * DGA tokens applied to Gravity Forms
 *
 * Unlike the header/footer/buttons/cards work, this is a pure CSS file with
 * NO blade template changes -- Gravity Forms' own markup (`.gfield`,
 * `.ginput_container`, `.gform_button`, etc.) is standard and stable across
 * every GF site, so there was something reliable to target directly.
 *
 * This site already had a form.css (resources/styles/form.css) using
 * Tailwind `@apply` directives for rough field styling. That file is left
 * alone -- it's compiled through the theme's Bud/Tailwind build, which
 * wasn't confirmed running in this environment, so editing it risked a
 * silent no-op (same reasoning as the buttons/cards work). This file loads
 * after it and overrides with real DGA values.
 *
 * Source of truth: DGA's real `.input`, `.checkbox`, `.textarea` component
 * CSS from @platformscode/core. Verified against the live "Complaints" form
 * (Gravity Forms id 3) on this local site to confirm the class names below
 * (`.large` on text inputs, `.gfield_label`/`.gform-field-label` on labels,
 * `.ginput_container_text` etc.) actually match what this install renders,
 * not just GF's generic docs.
 *
 * Native checkbox/radio note: DGA's real checkbox is a fully custom
 * component (hidden native input + a styled ::after icon overlay) that
 * Gravity Forms' plain `<input type="checkbox">` markup doesn't produce.
 * Rather than guess at replicating that custom visual on a native input,
 * this uses `accent-color` (the standard CSS property for recoloring native
 * form controls) set to DGA's real checked-state token -- correct color,
 * native browser behavior, no fragile pseudo-element reconstruction.
 */

/* ---- Creative Idea Submission Form (gform id 25), boxed width ----
 * Content bug, not a styling gap: this page's editor set up the same
 * 20% / 60% / 20% wp-block-columns layout used to center the form on
 * Invite/Meet His Excellency (compare the raw HTML: Invite's form
 * shortcode sits correctly INSIDE its 60% middle column) -- but on this
 * page the Gravity Forms shortcode ended up placed AFTER the columns
 * block instead of inside it, leaving all three columns empty and the
 * form rendering at the full page width instead of DGA's own ~730px
 * boxed form-page width (design.dga.gov.sa/guidelines/templates/form
 * uses `md:max-w-[730px] md:m-auto`). Fixing this by editing the raw
 * Gutenberg block content directly risks corrupting the block structure;
 * reproducing the same intended layout with CSS is safer and gives the
 * identical visual result. Desktop-only (min-width), matching how
 * Gutenberg's own Columns block already stacks to full width on mobile. */
@media (min-width: 1024px) {
  #gform_wrapper_25 {
    max-width: 730px;
    margin-inline: auto;
  }
}

/* ---- text / email / tel / number / password inputs ---- */
.gform_wrapper input[type="text"],
.gform_wrapper input[type="email"],
.gform_wrapper input[type="tel"],
.gform_wrapper input[type="number"],
.gform_wrapper input[type="password"],
.gform_wrapper input[type="url"],
.gform_wrapper select,
.gform_wrapper .textarea {
  height: 40px;
  padding: var(--spacing-none) var(--spacing-2) !important;
  border-radius: var(--radius-sm) !important;
  border: 1px solid var(--form-field-border-default) !important;
  background: var(--form-field-background-default) !important;
  color: var(--form-field-text-focused) !important;
  font-family: var(--font-family-arabic);
  font-size: var(--font-size-text-md);
  line-height: var(--line-height-text-md);
  transition: border-color 0.15s ease;
}

.gform_wrapper .textarea {
  height: auto;
  padding: var(--spacing-2) !important;
}

/* Client feedback: the field visibly shook/twitched on hover. Cause: the
   previous rule grew border-bottom from 1px to 2px and pulled margin-bottom
   -1px to compensate -- same jank already diagnosed and fixed for the
   Events page search input (assets/dga/dga-events.css), just not carried
   over here yet. An inset box-shadow paints the identical-looking bottom
   accent without ever changing the box's own border-width/margin, so nothing
   reflows. */
.gform_wrapper input[type="text"]:hover,
.gform_wrapper input[type="email"]:hover,
.gform_wrapper input[type="tel"]:hover,
.gform_wrapper input[type="number"]:hover,
.gform_wrapper input[type="password"]:hover,
.gform_wrapper input[type="url"]:hover,
.gform_wrapper select:hover,
.gform_wrapper .textarea:hover,
.gform_wrapper input[type="text"]:focus,
.gform_wrapper input[type="email"]:focus,
.gform_wrapper input[type="tel"]:focus,
.gform_wrapper input[type="number"]:focus,
.gform_wrapper input[type="password"]:focus,
.gform_wrapper input[type="url"]:focus,
.gform_wrapper select:focus,
.gform_wrapper .textarea:focus {
  border-color: var(--form-field-border-default) !important;
  box-shadow: inset 0 -2px 0 -1px var(--colors-neutral-600) !important;
  outline: none !important;
}

.gform_wrapper input::placeholder,
.gform_wrapper textarea::placeholder {
  color: var(--form-field-text-placeholder) !important;
  opacity: 1;
}

.gform_wrapper input:disabled,
.gform_wrapper select:disabled,
.gform_wrapper textarea:disabled {
  border-color: var(--border-disabled) !important;
  background-color: var(--background-disabled) !important;
  color: var(--text-default-disabled) !important;
}

/* ---- validation error state ---- */
.gform_wrapper .gfield_error input[type="text"],
.gform_wrapper .gfield_error input[type="email"],
.gform_wrapper .gfield_error input[type="tel"],
.gform_wrapper .gfield_error input[type="number"],
.gform_wrapper .gfield_error .textarea,
.gform_wrapper .gfield_error select {
  border-color: var(--form-field-border-error) !important;
}
.gform_wrapper .validation_message,
.gform_wrapper .gfield_validation_message {
  color: var(--text-error) !important;
  font-family: var(--font-family-arabic);
  font-size: var(--font-size-text-small);
  line-height: var(--line-height-text-small);
}
.gform_wrapper .gform_validation_errors {
  background-color: var(--background-error-light) !important;
  color: var(--text-error) !important;
}

/* ---- labels ---- */
.gform_wrapper .gfield_label,
.gform_wrapper .gform-field-label {
  font-family: var(--font-family-arabic);
  font-size: var(--font-size-text-small);
  line-height: var(--line-height-text-small);
  font-weight: var(--font-weight-semibold) !important;
  color: var(--text-default) !important;
}
.gform_wrapper .gfield_required {
  color: var(--text-error) !important;
}

/* ---- helper / description text ---- */
.gform_wrapper .gfield_description,
.gform_wrapper .gfield_consent_description {
  font-family: var(--font-family-arabic);
  font-size: var(--font-size-text-xs);
  line-height: var(--line-height-text-xs);
  color: var(--colors-text-tertiary) !important;
}

/* ---- checkbox / radio ----------------------------------------------------
   Client feedback: bring the same custom control already built for the
   "Was this page useful?" feedback form (partials/dga-feedback.blade.php,
   assets/dga/dga-feedback.css) to every checkbox/radio sitewide, not just
   Gravity Forms fields -- same appearance:none + custom ::after checkmark/
   dot recipe, same tokens, so a checkbox looks identical everywhere on the
   site regardless of which form renders it.
   This replaces the earlier native-`accent-color` compromise (see prior
   revision) now that the real recipe is proven to work directly on a plain
   native input -- the checkmark/dot ::after is positioned relative to the
   input itself (`position: relative` below).
   The hover ripple halo (see .dga-control-ripple below) DOES need a
   wrapping <span> like the feedback form's, which Gravity Forms' markup
   doesn't provide server-side -- assets/dga/dga-checkbox-radio-ripple.js
   adds one at runtime, so `z-index: 1` here keeps the input above that
   wrapper's ::before halo once it's inserted.
   !important throughout this shape block: Gravity Forms' own bundled CSS
   sets its own width/height/appearance/border-radius on these exact
   inputs at !important, so a plain rule here -- regardless of selector
   specificity -- silently lost every shape property to theirs, leaving a
   native-shaped control (client feedback: "checkboxes should be proper
   shape, radio button should be proper shape"). Same class of fight as
   the checked-state colours right below.
   margin-inline-end (not margin: 0): Gravity Forms' plain markup has no
   flex `gap` between the input and its <label> the way
   .dga-feedback__check/__radio do -- it relied entirely on the input's own
   default margin for that spacing, which margin:0 wiped out, causing the
   control to sit flush against (and visually overlap) the label text.
   .dga-feedback__check input/.dga-feedback__radio input (dga-feedback.css)
   is a more specific selector and still wins there, so this default only
   applies where nothing more specific already set the gap.
   The hover halo is 36px wide, centered on this 20px box, so it overflows
   8px past the box's own edge on hover -- worth knowing if this gap
   (currently 5px, client-requested) ever needs to grow again to fully
   clear the halo without touching the label text.
   This gap now lives on .dga-control-ripple (below), NOT here on the
   input -- when it was here, the wrapper (a flex item's margin still
   counts toward what an auto-sized flex container wraps around) grew to
   input-width + margin, so the wrapper's own geometric center -- which is
   what the halo centers on -- landed to the right of the checkbox itself
   instead of on it (client feedback: "gray circle showing in right
   align"). Margin outside the wrapper's own box doesn't affect that
   centering math at all.
   vertical-align:middle: inputs default to baseline alignment, which sat
   the box noticeably below the label text's vertical center. */
input[type="checkbox"],
input[type="radio"] {
  appearance: none !important;
  -webkit-appearance: none !important;
  box-sizing: border-box !important;
  width: 20px !important;
  height: 20px !important;
  margin: 0 !important;
  vertical-align: middle;
  flex: none;
  cursor: pointer;
  position: relative;
  z-index: 1;
  background: transparent !important;
  border: 1px solid var(--form-field-border-default) !important;
  transition: border-color 0.15s ease, background-color 0.15s ease;
}
input[type="checkbox"] {
  border-radius: var(--radius-sm) !important;
}
input[type="radio"] {
  border-radius: 50% !important;
}
input[type="checkbox"]:focus-visible,
input[type="radio"]:focus-visible {
  outline: 2px solid var(--button-background-primary-default);
  outline-offset: 2px;
}
input[type="checkbox"]:checked {
  /* !important on both: Gravity Forms' own compiled CSS carries a
     same-or-higher-specificity border/background rule for its checkbox
     inputs (same class of fight as the "Find Events" button and top-bar
     buttons elsewhere in this codebase) that otherwise wins and leaves the
     ring/fill at its default grey -- client feedback: the checked state
     only showed the ::after checkmark/dot, not the green ring/fill around
     it like the feedback form has. */
  background: var(--button-background-primary-default) !important;
  border-color: var(--button-background-primary-default) !important;
}
input[type="checkbox"]:checked::after {
  content: "";
  position: absolute;
  inset-inline-start: 6px;
  top: 2px;
  width: 6px;
  height: 11px;
  border: solid var(--colors-base-white);
  border-width: 0 2px 2px 0;
  transform: rotate(45deg);
}
input[type="radio"]:checked {
  /* !important: same GF-compiled-CSS fight as the checkbox rule above. */
  border-color: var(--button-background-primary-default) !important;
  background: transparent !important;
}
input[type="radio"]:checked::after {
  content: "";
  position: absolute;
  /* left (not inset-inline-start): this dot must sit dead-center in the
     radio box in BOTH directions. inset-inline-start flips to `right` in
     RTL, but the translate(-50%, -50%) below always shifts toward the
     physical left/up regardless of direction -- the two only cancel out
     correctly for LTR. In RTL they compound instead, pushing the dot off
     -center (client report: radio ring/dot misalignment on Arabic pages
     only). `left` is direction-agnostic, matching .dga-control-ripple
     ::before's own centering two rules below, which never had this bug. */
  left: 50%;
  top: 50%;
  width: 10px;
  height: 10px;
  border-radius: 50%;
  background: var(--button-background-primary-default);
  transform: translate(-50%, -50%);
}
/* Round grey hover halo, same recipe/token as .dga-feedback__control
   (assets/dga/dga-feedback.css) -- generalized (not tied to that
   component's class names) since dga-checkbox-radio-ripple.js wraps ANY
   plain checkbox/radio input in one of these at runtime. Sits behind the
   input (z-index: 1 on the input above) and scales in on hover only.
   Explicit 20x20 + align-self:center: client feedback -- the halo was
   showing off-center in some Gravity Forms fields. Cause: this wrapper is
   itself a flex item inside .gchoice/.gfield_checkbox rows, some of which
   stretch their children's cross-axis size (align-items:normal default,
   same root cause already documented above for the "Select All" toggle).
   A wrapper that ends up taller/shorter than its input centers the halo on
   ITS OWN (stretched) box, not the input's -- align-self:center stops the
   parent's stretch from resizing THIS flex item in the first place, so
   there's no longer a hardcoded 20x20 here duplicating the input's own
   size: a hardcoded value that has to be kept in sync with the input is
   exactly what caused the halo/box to visibly clip or sit slightly
   misaligned in some contexts (client feedback, two rounds of screenshots).
   Letting inline-flex shrink-wrap its single child instead means the
   wrapper is ALWAYS exactly the input's real rendered size, in every
   context, with nothing to keep in sync.
   vertical-align:middle: once JS wraps the input, this wrapper (not the
   input) is what actually sits in the label's inline flow -- needs the
   same middle alignment the input rule sets for the brief pre-JS/no-JS
   fallback state. */
.dga-control-ripple {
  position: relative;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  align-self: center;
  vertical-align: middle;
  /* Label-side gap lives here, not on the input inside: margin on THIS
     element is outside its own box, so it can't affect the percentage
     centering math the ::before halo below uses against this box -- see
     the input rule's comment for why margin on the input itself broke
     that centering. */
  margin-inline-end: 5px !important;
  line-height: 0;
  flex: none;
}
.dga-control-ripple::before {
  content: "";
  position: absolute;
  top: 50%;
  left: 50%;
  width: 36px;
  height: 36px;
  border-radius: 50%;
  background: var(--controls-control-ripple-effect);
  transform: translate(-50%, -50%) scale(0);
  transition: transform 0.2s ease-in-out;
  z-index: 0;
  pointer-events: none;
}
/* Gravity Forms' own .gchoice row wrapper is the closest thing to the
   feedback form's <label> row -- hovering anywhere in it (including the
   choice's own <label> text, a sibling of the input, not a descendant)
   shows the ripple, matching that same "hover the whole row" behaviour.
   The plain :hover fallback covers the wrapper being used somewhere with
   no .gchoice ancestor.
   Deliberately NOT :focus-within: a checkbox/radio keeps focus after being
   clicked (whether it ends up checked or not), so that trigger left the
   halo stuck "on" for whichever one was last clicked, even after the mouse
   moved away or selected a different radio in the same group -- client
   feedback: "that gray shape should be only for hover state". */
.dga-control-ripple:hover::before,
.gchoice:hover .dga-control-ripple::before {
  transform: translate(-50%, -50%) scale(1);
}
.gform_wrapper .gform-field-label--type-inline,
.gform_wrapper .gchoice label {
  font-family: var(--font-family-arabic);
  font-size: var(--font-size-text-md);
  line-height: var(--line-height-text-md);
  color: var(--text-default);
}
/* Client feedback: on a checkbox field with "Select all choices" enabled
   in the field's own Gravity Forms settings, the "Select All" toggle sits
   visibly lower than the checkboxes beside it. Root cause: .gfield_checkbox
   is a flex row holding both the .gchoice items AND the toggle button as
   siblings, with the default align-items:normal (= stretch) -- the
   toggle's own wrapper is taller (44px measured) than a single checkbox+
   label row, so it stretches to fill that height with its text centered
   inside, while the shorter checkbox items sit flush at the top of the
   same stretched row. Centering every item on the same line fixes it
   regardless of which one is naturally taller. */
.gform_wrapper .gfield_checkbox {
  align-items: center;
}
/* Reverted 2026-09-17: a sitewide `.gchoice { display:flex }` fix for the
   "Type of Complaint" field's wrapped-label hanging-indent (Complaints
   form, form 3 field 12) broke row spacing on every OTHER checkbox/radio
   field sitewide (rows started touching/overlapping) -- this field's own
   long labels are the exception, not the norm, so scoped to that field
   specifically below instead of a blanket `.gchoice` rule. */
#field_3_12 .gchoice {
  margin-bottom: 10px;
  display: flex;
}
#field_3_12 .gchoice label {
  margin-left: 10px;
}

/* ---- submit button ----
 * Two different Gravity Forms markup generations exist on this install:
 * the classic underscore convention (.gform_button, verified against the
 * "Complaints" form, id 3) and the newer "Orbital" theme's hyphenated
 * convention (.gform-button, seen on the pre-footer "Subscribe" form,
 * id 5) -- GF renders whichever the form's own theme setting picked, so
 * both need covering or some forms silently fall back to GF's own
 * unstyled default. */
.gform_wrapper .gform_button,
.gform_wrapper input.gform_button,
.gform_wrapper button.gform_button,
.gform-button,
button.gform-button,
input.gform-button {
  background-color: var(--button-background-primary-default) !important;
  color: var(--text-oncolor-primary) !important;
  border-radius: var(--radius-sm) !important;
  border: 0 !important;
  font-family: var(--font-family-arabic);
  font-weight: var(--font-weight-semibold) !important;
  height: 40px;
  padding-inline: var(--buttons-lg-padding) !important;
  transition: background-color 0.15s ease;
  /* Client feedback: submit buttons stretched full-width sitewide -- traced
     to resources/styles/form.css's own `w-full` Tailwind utility on this
     exact selector. DGA's real form-page reference (Next/Back buttons)
     sizes buttons to their content, not the full field width. !important
     here beats that rule the same way every other property on this
     selector already does (that file loads first, this one after). */
  width: auto !important;
}
.gform_wrapper .gform_button:hover,
.gform_wrapper input.gform_button:hover,
.gform_wrapper button.gform_button:hover,
.gform-button:hover,
button.gform-button:hover,
input.gform-button:hover {
  background-color: var(--button-background-primary-hovered) !important;
}

/* Client feedback: every datepicker field showed a solid green square
   button next to the date input -- traced to Gravity Forms' own calendar
   toggle button carrying the literal class `gform-button` alongside its
   own `gform-datepicker-toggle` classes, so it was unintentionally
   catching the sitewide submit-button styling above as if it were a
   primary CTA. DGA's real Date Picker has no separate button at all
   (clicking the text input itself opens the calendar) -- this can't
   remove the button without breaking the field's own keyboard/aria
   affordance (aria-label="Choose date on calendar"), so it's restyled
   as a minimal ghost icon instead of a bold filled button, closer to
   DGA's intentionally understated calendar affordance. Needs to come
   after the general rule above to win the specificity tie (same
   .gform-button class, extra .gform-datepicker-toggle class added). */
.gform_wrapper .gform-datepicker-toggle.gform-button {
  background-color: transparent !important;
  border: 1px solid var(--form-field-border-default) !important;
  color: var(--text-secondary-paragraph) !important;
  width: 40px !important;
  padding: 0 !important;
}
.gform_wrapper .gform-datepicker-toggle.gform-button:hover {
  background-color: var(--background-neutral-50, var(--colors-neutral-50)) !important;
  border-color: var(--form-field-border-hovered) !important;
}
.gform_wrapper.gravity-theme .ginput_container_date .gform-datepicker-toggle-icon {
  margin-left: 4px;
  margin-top: -4px;
}
/* Client request: replace the default GF datepicker calendar SVG icon with the
   custom calendar-04.png asset. The toggle button is a 40x40px ghost button
   (see .gform-datepicker-toggle rules above) -- the icon SVG inside it is
   hidden and the button's own background-image is set to the custom PNG,
   sized/centered to fill the button area neatly. */
.gform_wrapper .gform-datepicker-toggle.gform-button {
  background-image: url('./calendar-04.png') !important;
  background-repeat: no-repeat !important;
  background-position: center !important;
  background-size: 20px 20px !important;
}
.gform_wrapper .gform-datepicker-toggle-icon,
.gform_wrapper .gform-datepicker-toggle-icon svg {
  display: none !important;
}

/* On a dark/colored section (e.g. the pre-footer newsletter signup), a
   solid primary-green button on a dark-green background has poor
   contrast -- use DGA's real "on-color" button token instead, same
   pattern as dga-buttons.css's on-color variant. */
.dga-pre-footer .gform-button,
.dga-pre-footer .gform_button {
  background-color: var(--button-background-oncolor-default) !important;
  color: var(--colors-primary-sa-flag-700) !important;
}
.dga-pre-footer .gform-button:hover,
.dga-pre-footer .gform_button:hover {
  background-color: var(--button-background-oncolor-hovered) !important;
}

/* Same dark-background problem for the field description text ("We care
   about your data in our privacy policy"): the sitewide .gfield_description
   rule above uses --colors-text-tertiary, which resolves to a lavender
   brand color (a naming collision in dga-tokens.css between "tertiary
   text hierarchy" and "tertiary brand color", not an on-purpose choice) --
   unreadable on this dark green section. Use DGA's real on-color text
   token instead. */
.dga-pre-footer .gfield_description {
  color: var(--text-oncolor-secondary) !important;
}
.dga-pre-footer .gfield_description a {
  color: var(--text-oncolor-primary) !important;
}

/* ---- file upload ----
 * DGA's real File Uploader anatomy: drag-drop area, title/helper text,
 * browse button, featured icon, per-file status/delete. Gravity Forms'
 * own multi-file uploader (.gform_drop_area + .gform_button_select_files,
 * Plupload-driven) already matches that anatomy's core shape and is
 * independently keyboard-accessible -- styled directly rather than
 * rebuilt, same reasoning as checkbox/radio/dropdown elsewhere in this
 * file. Confirmed 9 real published forms (Complaints, Vendor
 * Registration, Data Request, etc.) actually use this field type.
 * Single-file mode (max_files=1) falls back to a plain <input
 * type="file">, styled separately below since it has no drop area.
 */
.gform_wrapper .gform_drop_area {
  border: 2px dashed var(--form-field-border-default);
  border-radius: var(--radius-md);
  background: var(--background-neutral-25, var(--colors-neutral-50));
  padding: var(--spacing-6) var(--spacing-4);
  text-align: center;
  transition: border-color 0.15s ease, background-color 0.15s ease;
}
.gform_wrapper .gform_drop_area.gform_drop_area--active,
.gform_wrapper .gform_drop_area:hover {
  border-color: var(--form-field-border-hovered);
  background: var(--background-primary-25, var(--colors-primary-sa-flag-50));
}
.gform_wrapper .gform_drop_instructions {
  display: block;
  margin-bottom: var(--spacing-3);
  font-family: var(--font-family-arabic);
  font-size: var(--font-size-text-md);
  line-height: var(--line-height-text-md);
  color: var(--text-primary-paragraph);
}
.gform_wrapper .gform_button_select_files {
  border: 1px solid var(--border-neutral-primary) !important;
  border-radius: var(--radius-sm) !important;
  background: var(--background-card) !important;
  color: var(--text-default) !important;
  font-family: var(--font-family-arabic);
  font-weight: var(--font-weight-medium);
  padding: var(--spacing-2) var(--spacing-4) !important;
  transition: background-color 0.15s ease;
}
.gform_wrapper .gform_button_select_files:hover {
  background: var(--background-neutral-50) !important;
}
.gform_wrapper .gform_fileupload_rules {
  display: block;
  margin-top: var(--spacing-2);
  font-family: var(--font-family-arabic);
  font-size: var(--font-size-text-small);
  color: var(--text-secondary-paragraph);
}

/* Single-file custom upload box -- a DIFFERENT, older implementation
 * (resources/styles/form.css, compiled into the Tailwind bundle) already
 * exists for the .ginput_container_fileupload path used by every form
 * checked so far (Complaints id 3, etc.): native input hidden via
 * opacity, label styled to look like a clickable box with a background
 * icon. Its colors reference undefined custom properties with hardcoded
 * hex fallbacks (var(--Gray-200, #EAECF0)), not any real DGA token --
 * !important needed since the compiled bundle loads after this file. */
.ginput_container.ginput_container_fileupload {
  border: 1px solid var(--form-field-border-default) !important;
  /* Client feedback: this rendered as a plain white box, indistinguishable
     from a text input -- DGA's real File Uploader anatomy uses a light
     neutral-tinted background for the whole drop area (same token already
     used for the OTHER file-upload implementation, .gform_drop_area,
     right above), not the plain form-field white. */
  background: var(--background-neutral-25, var(--colors-neutral-50)) !important;
}
.ginput_container_fileupload label {
  color: var(--text-default) !important;
}

/* Single-file fallback (native <input type="file">, no drop area) */
.gform_wrapper input[type="file"] {
  border: 1px solid var(--form-field-border-default) !important;
  border-radius: var(--radius-sm) !important;
  background: var(--form-field-background-default) !important;
  padding: var(--spacing-2) !important;
  font-family: var(--font-family-arabic);
  font-size: var(--font-size-text-md);
}
.gform_wrapper input[type="file"]::file-selector-button {
  border: 1px solid var(--border-neutral-primary);
  border-radius: var(--radius-sm);
  background: var(--background-card);
  color: var(--text-default);
  font-family: var(--font-family-arabic);
  padding: var(--spacing-1) var(--spacing-3);
  margin-inline-end: var(--spacing-3);
  cursor: pointer;
}

/* List field add/remove-row icon buttons (Gravity Forms' "Orbital" theme
 * framework, e.g. Meet/Invite His Excellency's "Guest Attendees" repeater).
 * Framework colors these via its own --gf-* custom properties which
 * resolve to a plain gray, not any DGA token. Attempted override below on
 * both the button and its ::before (the icon glyph is CSS-generated
 * content, the "Add"/"Remove" text itself is font-size:0'd away) did NOT
 * visually take effect when checked via screenshot -- some other rule in
 * gravity-forms-theme-framework.min.css still wins despite !important,
 * root cause not pinned down (would need real browser DevTools computed-
 * style inspection, not available in this sandbox). Left in as a safe
 * no-op rather than reverted, in case it's actually partially working via
 * a mechanism the screenshot didn't reveal, or starts working once a real
 * browser is used to inspect/adjust it. This is a very minor, secondary
 * control (a repeater row add/remove icon) -- not worth further blind
 * guessing at the CSS cascade; flag for the user's own DevTools if it
 * ever matters enough to prioritize. */
.add_list_item,
.delete_list_item,
.add_list_item::before,
.delete_list_item::before {
  border-color: var(--colors-primary-sa-flag-600-primary) !important;
  color: var(--colors-primary-sa-flag-600-primary) !important;
}
.add_list_item:hover,
.delete_list_item:hover,
.add_list_item:hover::before,
.delete_list_item:hover::before {
  border-color: var(--colors-primary-sa-flag-700) !important;
  color: var(--colors-primary-sa-flag-700) !important;
}