/* ==========================================================================
   forms.css - Contact Form 7's own markup, styled to look like the build.

   This file is DELIBERATELY kept SEPARATE from `custom.css`.

   `custom.css` is a copy of the HTML build - whenever the client updates the
   build's CSS, that whole file gets replaced. Anything written in there would
   silently vanish next time. This file holds only the rules that are needed
   because of WordPress/CF7, which have no existence at all in the build.

   In the build the forms were for show only - no validation, no error
   messages. So the build has no error styling whatsoever, and CF7's own
   defaults were showing through.
   ========================================================================== */

:root {
  /* CF7's default is `.wpcf7-not-valid-tip { font-size: 1em }` - meaning it
     takes its size from the body copy, and on this site `--fs-body` goes up
     to 24px. The error message looked as big as a heading. */
  --fs-err: 16px;
}

/* --------------------------------------------------------------- field tip */

/* CF7 inserts this span inside every invalid field:
     <span class="wpcf7-not-valid-tip" aria-hidden="true">...</span>
   It is `aria-hidden` - the real screen-reader message goes into the
   separate, hidden `.screen-reader-response` - so it is fine to style this
   purely for how it looks. */
.wpcf7-not-valid-tip {
  display: block;
  margin-top: 6px;
  font-size: var(--fs-err);
  font-weight: 500;
  line-height: 1.3;
  letter-spacing: 0;
  color: var(--red);
}

/* Give the invalid field its own marker - otherwise there is only the text
   written below it, and in a small form the eye is somewhere else.

   Only on the REAL control. `.wpcf7-not-valid` is also applied to the GROUP
   span of checkboxes/radios, and an outline there boxes in the whole label,
   which looks wrong. */
input.wpcf7-not-valid,
textarea.wpcf7-not-valid,
select.wpcf7-not-valid {
  outline: 2px solid var(--red);
  outline-offset: 1px;
}

/* --------------------------------------------------------- response banner */

/* CF7's default: a 2px blue border, `margin: 2em .5em 1em`. It opened up a
   big box under the footer's slim signup form. */
.wpcf7 form .wpcf7-response-output {
  margin: 12px 0 0;
  padding: 0;
  border: 0;
  font-size: var(--fs-err);
  line-height: 1.3;
  color: var(--red);
}

/* REMOVE THE BANNER in the small newsletter form.
   A blank submit produced three messages:
       "One or more fields have an error..."   <- banner
       "Please fill out this field."           <- email's tip
       "Please fill out this field."           <- consent's tip
   Two fields are required, so two tips are correct - they sit under their
   own separate controls. But the banner just repeats what they say, and a
   three-line form turned into a four-line error.
   The big forms (contact, entry) keep the banner - there a field can be off
   screen and a summary at the top is needed. */
.ft-news-form .wpcf7-response-output,
.connect-form .wpcf7-response-output,
.wpcf7-form.ft-news .wpcf7-response-output {
  display: none;
}

/* ------------------------------------------------------------------ spinner */

/* CF7 inserts a spinner span AFTER every `.has-spinner`. Its default is
   `visibility: hidden` - meaning it is invisible but still TAKES UP SPACE:
   a 24px circle plus 24px margin on each side = 72px.
   `.ft-news-row` is a flex column, so that 72px empty slot landed under the
   button. So when it is hidden it must not take up space either. */
.wpcf7-spinner {
  position: absolute;
  margin: 0;
}

.wpcf7-form.submitting .wpcf7-spinner {
  position: static;
  margin: 0 0 0 12px;
}

/* -------------------------------------------------------- save the checkbox */

/* In the build these forms had ONLY ONE input - email - so the rule was
   written without any qualifier:

       .connect-form input { width: clamp(200px,36.47vw,700px); height: 80px;
                             background:#fff; margin-top: 47px }

   WordPress added a consent checkbox to that same form (for GDPR), and that
   rule catches it too - the checkbox became a 700x80 white box in the middle
   of the form, with the pieces of "I agree to receive updates." scattered
   around it.

   The footer and contact form would suffer the same, so reset in all three.

   CAUTION - this reset must ONLY apply to forms where a build `input` rule
   catches the checkbox. Previously `.wpcf7 input[type="checkbox"]` was also
   written here - site-wide. That made the Award Entry checkboxes DISAPPEAR:

       .ae-form input[type="checkbox"] { appearance:none; width:37px;
                                         height:37px; border:1px solid red }

   There the build hides the native box and draws its own 37px red box. Both
   selectors have specificity (0,1,1), and forms.css loads later - so the
   blanket reset won, and `width:auto` together with `appearance:none` means:
   nothing is drawn at all. The input is present in the markup, nothing on
   screen. */
.connect-form input[type="checkbox"],
.ft-news-consent input[type="checkbox"],
.connect-consent input[type="checkbox"] {
  width: auto;
  height: auto;
  min-height: 0;
  margin-top: 0;
  padding: 0;
  background: none;
  accent-color: var(--red);
}

/* ------------------------------------------------- entry form tick */

/*
   WHITE TICK on the Award Entry checkboxes.

   The build has no tick at all - custom.css:2419 does only this:

       .ae-form input[type="checkbox"]:checked { background: var(--red); }

   So on ticking, the box simply fills red. With `appearance: none` the
   browser's own tick is gone too, so the user only sees a colour change -
   and the empty box already has a red border, so the difference between
   "checked" and "unchecked" is barely noticeable.

   The tick comes from an SVG data-URI, not a separate file - saves an extra
   HTTP request and there is no question of the file going missing.

   `background-image` is written separately, not as shorthand: the build's
   `background: var(--red)` is shorthand and would reset the image. Keeping
   the two apart means the red keeps coming from there and the tick from here.

   Specificity is deliberately (0,4,1) - `.wpcf7-form` alongside `.ae-form`.
   The build's rule is (0,3,1), so this wins in every load order. Relying on
   equal specificity alone would make the tick silently vanish the moment
   forms.css changed position in the load order.

   The box is tilted `-10deg`; the tick rotates with it - same as the design.
*/
/*
   The same tick on radios TOO.

   Award category is a `[radio]`, not a checkbox - so previously the tick
   applied only to checkboxes and choosing a category showed just a red box.

   Normally a radio has a dot, not a tick. But in this build the two are
   identical - same size, same 4px radius, same -10deg tilt (custom.css:2406
   has both in a single rule). Giving them different marks would show two
   kinds of control in one form, which would look even stranger.
*/
.ae-form.wpcf7-form input[type="checkbox"]:checked,
.ae-form.wpcf7-form input[type="radio"]:checked {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%23ffffff' stroke-width='3.2' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpolyline points='4.5 12.5 9.5 17.5 19.5 6.5'/%3E%3C/svg%3E");
  background-repeat: no-repeat;
  background-position: center;
  background-size: 60%;
}

/*
   Award category radio 5px lower.

   The build has `.cat-cell input { margin-top: clamp(4px, 1.0453vw, 20.07px) }`
   (custom.css:2453). At that size the box sits slightly above the label's
   text - `.cc-t` uses the `--h4` font (up to 36px) and its line box is a good
   deal taller than the radio.

   The `calc()` keeps the build's exact clamp and adds 5px on top - so the
   nudge stays constant at every screen width and the build's responsive
   scaling is preserved too. A fixed value would look right at 1920 and
   different at every other width.

   Only above 768px. On mobile the build has its own `margin-top: 2px`
   (custom.css:2641) - the layout is different there (cells in one column)
   and adding the nudge would push the radio below the label.
*/
@media (min-width: 768px) {
  .ae-form .cat-cell input {
    margin-top: calc(clamp(4px, 1.0453vw, 20.07px) + 5px);
  }
}

/* ------------------------------------------------------------- consent row */

/* This checkbox DOES NOT EXIST IN THE BUILD - it came from the WordPress side
   (consent for the newsletter). So there is no rule for it in the build's
   CSS and the styling has to live here.

   The space that used to show above it actually belonged to CF7's hidden
   spinner (24px circle + 48px margin). As soon as the spinner was removed,
   consent was pressed up against SUBMIT - hence its own margin now. */
.ft-news-consent,
.connect-consent {
  display: flex;
  align-items: baseline;
  flex-wrap: wrap;
  gap: 4px 8px;
  margin-top: clamp(12px, 1.0417vw, 20px);
  font-size: var(--fs-label);
  line-height: 1.35;
  letter-spacing: 0;
}

/* CF7 wraps the checkbox in three spans:
     .wpcf7-form-control-wrap > .wpcf7-checkbox > .wpcf7-list-item > label
   The middle spans become flex items and take a line of their own, so remove
   them from the layout - the checkbox and its text stay on one line. */
.ft-news-consent > .wpcf7-form-control-wrap,
.connect-consent > .wpcf7-form-control-wrap,
.ft-news-consent .wpcf7-checkbox,
.connect-consent .wpcf7-checkbox {
  display: contents;
}

.ft-news-consent .wpcf7-list-item label,
.connect-consent .wpcf7-list-item label {
  display: inline-flex;
  align-items: baseline;
  gap: 8px;
}

/* The Stay Connected band is on blue - the text there needs to be white. */
.connect-consent,
.connect-consent a {
  color: #fff;
}

/* CF7 gives every list item `margin: 0 0 0 1em` - on a single checkbox that
   becomes a pointless indent. */
.ft-news-consent .wpcf7-list-item,
.connect-consent .wpcf7-list-item {
  margin: 0;
}

/* --------------------------------------------------------------- wrappers */

/* CF7 wraps every control in `<span class="wpcf7-form-control-wrap">`. That
   span does not exist in the build, so in a flex/grid row the span becomes
   the FLEX ITEM, not the input - and the width/gap drift away from the build.
   `display: contents` removes the span from the layout and the input becomes
   a direct child again. The tip is still inside it, so it too lands on its
   own line in the row. */
.ft-news-row > .wpcf7-form-control-wrap,
.ct-field > .wpcf7-form-control-wrap {
  display: contents;
}

/*
   NO `display: contents` on `.fld-cols` - there it breaks the layout on
   error.

   `.fld-cols` is a grid (custom.css:2401 - `1fr 1fr`). `display: contents`
   removes the span from the layout and the input becomes a direct grid
   child - fine on a valid form: two inputs, two columns.

   But on an invalid submit CF7 inserts another span INSIDE the wrap:

       <span class="wpcf7-form-control-wrap">
         <input>
         <span class="wpcf7-not-valid-tip">Please fill out this field.</span>
       </span>

   With `display: contents` that tip becomes a grid child TOO. Now the grid
   has FOUR children instead of two:

       Email input -> col 1        Email tip   -> col 2
       Confirm     -> col 1 row 2  Confirm tip -> col 2 row 2

   So Email and Confirm Email leave their shared row and stack one above the
   other, and the error message ends up beside the input.

   The first attempt to fix this was `flex-basis: 100%` - but that is a flex
   property and `.fld-cols` is a grid, so it had no effect at all.

   The right fix: let the wrap stay a normal grid item. Then the grid gets
   exactly two children (the two wraps), and each tip drops under its own
   input - the columns do not break.
*/
.fld-cols > .wpcf7-form-control-wrap {
  display: block;
  min-width: 0;
}

/* The entry form's checkbox groups.
   `gga_cf7_choice_lists()` converts them into the build's `<ul><li>`, but
   that list sits inside TWO CF7 spans:

       .heard-cols > span.wpcf7-form-control-wrap > span.wpcf7-checkbox > ul

   `.heard-cols` is a grid and the two `<ul>` must be its DIRECT children -
   otherwise the grid sees only one child (the span) and both lists end up in
   a single column. Remove both spans from the layout. */
.heard-cols > .wpcf7-form-control-wrap,
.heard-cols .wpcf7-checkbox,
.org-type > .wpcf7-form-control-wrap,
.org-type .wpcf7-checkbox {
  display: contents;
}

/* When the group is invalid the tip now drops inside the list - send it to
   its own full-width line. */
.heard-cols .wpcf7-not-valid-tip,
.org-type .wpcf7-not-valid-tip {
  grid-column: 1 / -1;
}

/* ------------------------------------------------------ document upload */

/* The sizing is NOT repeated here. `gga_cf7_file_button()` puts the
   `.btn-files` class on the label, so the build's own box (width/height/margin
   clamps, radius, teal, font) applies by itself - and if the client delivers
   new build CSS this keeps working with it. */

/* Remove CF7's wrapper span, otherwise the input and label are trapped inside
   it and `.up-drop` sees only one child. */
.up-drop > .wpcf7-form-control-wrap { display: contents; }

/* Hide the native control - but NOT with `display:none`. When a required
   file is empty the browser tries to focus it; with `display:none` that
   fails and the error never shows anywhere. */
.up-drop input[type="file"].gga-file {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  border: 0;
  overflow: hidden;
  clip: rect(0 0 0 0);
  white-space: nowrap;
}

/* A `<button>` centres its own text; a `<label>` does not. */
.up-drop label.btn-files {
  display: flex;
  align-items: center;
  justify-content: center;
}

/* The input is invisible, so the keyboard focus ring goes on the label. */
.up-drop input[type="file"].gga-file:focus-visible + label.btn-files {
  outline: 2px solid var(--purple);
  outline-offset: 2px;
}

/* -------------------------------------- "Submit Your Entry" box bottom */

/*
   The red intro box had 30px too much space below the content.

   custom.css:2336 has the padding:

       padding: 23.32px 71.21px clamp(24px, 5.7766vw, 110.91px)

   So 110.91px at the bottom @1920. In Figma it is 81px:

       .ae-form-intro   y 8604.6  h 460.1  ->  bottom 9064.7
       .ae-fi-body      y 8834.2  h 149.4  ->  bottom 8983.6
       gap              9064.7 - 8983.6    =   81.1px

   Measured live: 111px below the body - 30px more than Figma.

   The new clamp's vw is derived from Figma: 81.1 / 1920 = 4.2240vw. That
   keeps the same proportion the design has at every width; a fixed 81px
   would be right only at 1920.

   Min 24px is the build's own - below 768px custom.css's own mobile rule
   (`padding: 24px 20px 28px`) applies anyway.
*/
.ae-form-intro {
  padding-bottom: clamp(24px, 4.2240vw, 81.1px);
}

/*
   Line-height of the red box's text, from Figma.

   The build has `line-height: normal` on both (custom.css:2347, 2355). In
   this font `normal` gives ~1.25, but Figma has an explicit line-height:

       .ae-fi-lead   36px font, Figma line 53.4px  ->  1.4833
       .ae-fi-body   24px font, Figma line 37.35px ->  1.5563

   Measured difference:

       lead   live 45px    Figma 53.4px    -8.4
       body   live 120px   Figma 149.4px   -29.4   (4 lines x 7.35)

   That same 29.4px was what the box's height was short by.

   Written as a unitless ratio, not px - so the line-height scales with the
   font-size by itself. `--fs-body` and `--h4` are both clamps; in px the
   line-height would stay bigger than the font on small screens and the text
   would look spread out.
*/
.ae-fi-lead { line-height: 1.4833; }
.ae-fi-body { line-height: 1.5563; }

/*
   The gap between lead and body.

   custom.css:2350 has `margin-top: clamp(10px, 0.6188vw, 11.88px)` =
   11.88px @1920. In Figma it is 3.8px:

       .ae-fi-lead  y 8777.0  h 53.4  ->  bottom 8830.4
       .ae-fi-body  y 8834.2             ->  gap 3.8

   That 8.1px difference was adding straight onto the box's height (468 vs
   460).

   Note: this could only be fixed once the line-height was right first. While
   the lead was 45px (instead of 53.4), changing this margin would just have
   covered one mistake with another - the box height would match by
   coincidence but the text would not be in its place.

   3.8 / 1920 = 0.1979vw.
*/
.ae-fi-body { margin-top: clamp(3px, 0.1979vw, 3.8px); }

/* ------------------------------------------- award category grid rule */

/*
   Bring back the top rule of `.cat-grid` - it is what shows under the
   Organisation field.

   Two rules in custom.css are in conflict:

       2424  .ae-form fieldset { ... border: 0 }        (0,1,1)
       2426  .cat-grid { border-top: 0.8px solid ... }  (0,1,0)

   `.ae-form fieldset` has an ELEMENT alongside the class, so its specificity
   is higher - and it swallows the border-top of `.cat-grid`. The line was
   never rendered, even though it was written in the CSS.

   This is NOT an ordering issue - `border: 0` is written earlier and still
   wins. So moving `.cat-grid` later achieves nothing; the specificity has to
   be raised.

   `fieldset.cat-grid` = (0,2,1) - now this wins.

   The line is in Figma too: `.fld-lead input` ends at bottom 9246.1 and
   Line 80 (.cat-grid) is at 9269.6 - 23px below, which matches the 21.44px
   padding-bottom of `.fld-lead`.
*/
.ae-form fieldset.cat-grid {
  border-top: var(--rule-w) solid var(--rule);
}

/* --------------------------------------------- award category grid (mobile) */

/* Below 767px `.cat-grid` becomes flex and the cells take `order: 1..7`.
   CF7's empty wrap span is a flex item too and its order is 0 - so the
   validation error renders ABOVE ALL SEVEN categories.
   The order has to go on the span: the tip itself is not a flex item, its
   parent is. */
.cat-grid > .wpcf7-form-control-wrap { order: 8; }

/* The single checkboxes for Declaration and Terms.
   Build: `<div class="tick"><input><label>…</label></div>` - both direct
   flex children. CF7's two spans get in between, so `.tick` sees only one
   inline child; its line box also takes up descender space and the row
   becomes 34px instead of 28px. */
.tick > .wpcf7-form-control-wrap,
.tick .wpcf7-acceptance {
  display: contents;
}

/* After `display: contents` the tip no longer has a box of its own, so send
   it to full width or it sticks to the side of the input.

   Only `.ft-news-row` - that one is FLEX, so `flex-basis` works there.
   `.fld-cols` was removed from here: it is a grid (flex-basis was useless
   there) and its wraps are now `display: block`, so the tip drops under the
   input by itself - see the note above. */
.ft-news-row .wpcf7-not-valid-tip {
  flex-basis: 100%;
  width: 100%;
}

/* ------------------------------------------------------------ entry submit */

/* The Underscores reset (style.css:563) gives `button` a `padding: .6em 1em
   .4em`. custom.css's `button {}` reset never touches padding, so inside the
   fixed height of .btn-submit .6em (up to 18px) came in from the top and the
   "Submit Entry" text was CUT OFF at the bottom. The build has no underscores
   at all, so it never showed there.
   Left stays with custom.css's `.btn-submit { padding-left: clamp(...) }` -
   only top/right/bottom are zeroed here. */
.btn-submit.wpcf7-submit {
  padding-top: 0;
  padding-right: 0;
  padding-bottom: 0;
}

/*
   The last letter of "Submit Entry" was spilling out of the button.

   The button's size is EXACTLY right from Figma (Rectangle 103: 227.6 x 54.3)
   and custom.css:2584 has that same clamp. The problem was the text:

       button                227.6px
       padding-left           12.3px
       left for text         215.3px
       "Submit Entry" @40px  218.0px   ->  2.7px over

   It has `white-space: nowrap`, so the text does not wrap - it simply runs
   out of the teal box and the "y" looks half cut off.

   The Figma spec never included the TEXT node of this button (only the
   rectangle is mapped), so the font-size cannot be taken from there. But the
   button's width comes from the design, and 218px of text does not fit in
   215px - meaning the browser's rendering is slightly wider than Figma's
   (font metrics difference; the site uses the Plus Jakarta Sans web font).

   So the button's size was NOT TOUCHED - it comes from the design. The font
   went from 40 to 39, which makes the text 212.6px and leaves 2.7px to
   spare. A 1px difference is invisible, but the clipping stops.

   vw in the same proportion: 39 / 1920 = 2.0313vw.
*/
.btn-submit {
  font-size: clamp(21px, 2.0313vw, 39px);
}

/* ------------------------------------------- large file upload + loader */

/*
   A 2 GB file goes up in chunks (inc/upload.php). This is the visible part of
   that - each file on its own line, with its own bar.

   The loader is COMMUNICATION, not decoration. An 800 MB annual report takes
   several minutes even on 4G; if nothing shows for all that time the user
   thinks the form has stalled, and either presses Submit again or closes the
   tab - in both cases their entry is lost. So three things are always
   visible: how much has gone, how much is left, and that it is still
   running.

   The design has no such block - in the build's forms the upload was for
   show only. So the sizing is taken from the site's own tokens (--fs-body,
   --rule, --teal) - when a new build arrives this changes along with it.
*/

/*
   `[text* annual-report]` is NOT VISIBLE - the user never types into it.

   It is a channel that JS fills with the uploaded file's `slot/name`. CF7's
   `required` runs on it, and that same field goes into the mail - so both
   validation and notification stay on CF7's own path, and we do not have to
   rewrite any part of them.

   The INPUT is hidden, its WRAPPER is not. CF7's error tip
   (`.wpcf7-not-valid-tip`) also lives inside `.wpcf7-form-control-wrap` -
   hiding the wrapper means "Please upload your Annual Report ..." never
   shows anywhere and the user cannot work out why the form will not go.

   Not `display: none` - same reason as forms.css:344. The field is required;
   the browser tries to focus it, and with `display:none` that fails
   silently.
*/
input.gga-uploads {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  border: 0;
  overflow: hidden;
  clip: rect(0 0 0 0);
  white-space: nowrap;
}

.up-list {
  margin: clamp(12px, 1.0417vw, 20px) 0 0;
  padding: 0;
  list-style: none;
}

.up-item {
  padding: clamp(10px, 0.8333vw, 16px) 0;
  border-bottom: var(--rule-w) solid var(--rule);
}

.up-item-head {
  display: flex;
  align-items: baseline;
  gap: clamp(8px, 0.8333vw, 16px);
  font-size: var(--fs-body);
  line-height: 1.4;
}

/*
   Let the name shrink, not the meta.

   Without `min-width: 0` a flex item will not go below its min-content, and
   a file name is one long word with no spaces
   (EAadhaar_0811079290719120250104155119_1002.pdf) - it pushes the whole
   row out. The same problem existed with `.up-see` in theme.css.
*/
.up-item-name {
  flex: 1 1 auto;
  min-width: 0;
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
  font-weight: 600;
}

/* The numbers keep changing - without `tabular-nums` their width changes
   every frame and the whole line looks like it is trembling. */
.up-item-meta {
  flex: 0 0 auto;
  font-variant-numeric: tabular-nums;
  color: var(--blue-lt);
}

.up-item-btn {
  flex: 0 0 auto;
  padding: 0;
  border: 0;
  background: none;
  font: inherit;
  color: var(--purple);
  text-decoration: underline;
  cursor: pointer;
}
.up-item-btn:hover { color: var(--red); }

.up-bar {
  margin-top: clamp(6px, 0.5208vw, 10px);
  height: 6px;
  border-radius: 3px;
  background: var(--rule);
  overflow: hidden;
}

.up-bar span {
  display: block;
  height: 100%;
  width: 0;
  border-radius: inherit;
  background: var(--teal);
  transition: width .2s linear;
}

/*
   Faint stripes on the running bar.

   The bar's width grows very slowly - at 800 MB a single pixel takes several
   seconds - and a bar that is not moving looks "stuck". The stripes show
   that work is still going on, even when the number has not moved.
*/
.up-item.is-uploading .up-bar span {
  background-image: linear-gradient(
    90deg,
    rgba(255, 255, 255, .35) 25%, transparent 25%,
    transparent 50%, rgba(255, 255, 255, .35) 50%,
    rgba(255, 255, 255, .35) 75%, transparent 75%
  );
  background-size: 20px 20px;
  animation: gga-up-stripe 1s linear infinite;
}

@keyframes gga-up-stripe {
  from { background-position: 0 0; }
  to   { background-position: 20px 0; }
}

.up-item.is-done .up-bar span  { background: var(--teal); }
.up-item.is-error .up-item-meta { color: var(--red); }

/* Finished - a tick before the name, so it is clear at a glance. */
.up-item.is-done .up-item-name::before {
  content: "\2713\00a0";
  color: var(--teal);
}

.up-msg {
  margin-top: clamp(8px, 0.6250vw, 12px);
  font-size: var(--fs-body);
  line-height: 1.4;
  color: var(--blue-lt);
}
.up-msg.is-bad { color: var(--red); }

/* During an upload the zone itself should also say it is busy - the user is
   looking at the drop zone at that moment, not at the list. */
.up-zone.is-busy .up-drop { opacity: .6; }
.up-zone.is-busy .btn-files { pointer-events: none; }

/* Submit stays disabled during an upload (gga-upload.js). It cannot be
   pressed, so it should also look like it cannot be pressed right now. */
.wpcf7-submit:disabled {
  opacity: .5;
  cursor: not-allowed;
}

@media (prefers-reduced-motion: reduce) {
  .up-bar span { transition: none; }
  .up-item.is-uploading .up-bar span { animation: none; }
}