.new-request-page {
  .anonymous_message {
    display: none;
  }
  .anonymous_message.show {
    display: block;
  }

  .callout-support {
    align-items: flex-start;
  }

  /* The 1.25rem gap this used to set is the base now -- Codex's icon-to-text
     gap, css-components.css's callout section, 2026-10-25. */
  .callout-tip {
    align-items: center;
  }

  /* `.callout-tip svg` is gone: --step-5 and no top margin are what the base
     rule gives every callout icon now (css-components.css, Callouts). Its
     `width: 1em` went with it -- circle-check has a square viewBox, so the kit's
     <svg> is already 1em wide and the declaration changed nothing. */

  .form {
    overflow-anchor: none;
  }

  .form:has(
    [data-garden-id='dropdowns.combobox.trigger'][aria-expanded='true']
  ) {
    padding-block-end: 20rem;
  }
}

/* THE 16.5rem DESKTOP max-width IS GONE, and it was the real width of this
   panel: `.sidebar`'s target width is what sizes the column, but this cap
   clamped the panel inside it to 264px from 60em up. Joy, 2026-10-25: the panel
   should be "the same width as the search results categories side panel", which
   is 21.25rem -- now the `.sidebar` default (css-utilities.css), so this panel
   fills its column and there is nothing left for a cap to do. */
/* ---- The contact panel ----
   CODEX'S CARD SURFACE, `card-v2`. Joy, 2026-10-25: "I noticed we're missing a
   box shadow on the contact info box." The shadow was the visible half; the
   border and the fill were the other half, and all three come from one recipe.

   Declaration for declaration this is now .request-sidebar
   (css-page-request.css:543), which is the same thing on the same side of the
   next page along, and the resting state of .kb-section-card and
   .kb-update-card (css-components.css). Four places, one recipe: --neutral-bg
   fill, one hairline of --neutral-border-soft, --radius-md, and the
   0 2px 6px --shadow-regular drop. If Codex ever moves the card, the grep is
   `--shadow-y-offset`.

   WHAT THIS REPLACES, and why each line was legacy rather than merely different:

     - `border: 1px solid var(--clr-neutral-40)`. A primitive with ONE value in
       both themes, so in dark mode this panel kept a pale border around a dark
       surface. This file had zero dark-mode rules and 24 --clr-* references
       before this round; that is the central failure mode the branch exists to
       fix, not a cosmetic preference.
     - NO background-color at all, which is why Joy's eye went to the shadow:
       the panel was the page showing through a border, so there was no surface
       for a shadow to lift. --neutral-bg (#faffff light) is a hair off
       --page-bg-middle in light mode and clearly distinct in dark, which is the
       right relationship in both.
     - `border-radius: 0.5rem` was 8px by hand. --radius-md is 8px, so this is
       the same corner named rather than measured.

   THE PADDING IS --space-s, NOT THE FACETS CARD'S `1.25rem 1rem`, and this is
   the one place the page deliberately does not copy the search results panel.
   16px is Codex's space/4 and the card component's own padding, which
   .request-sidebar and both card components already take; #algolia-facets's
   extra 4px of block padding comes from that widget's specific frame. Matching
   the component rather than the one instance keeps the two sidebars identical,
   which is what Joy asked for the WIDTH of (see the note above). Say so and it
   is a 4px change away from being the other way. It IS a size change either way,
   though: the old --space-xs is a fluid 12-18px and --space-s is 16-24px, so the
   card's contents move in by about 4-6px.

   TWO THINGS DELIBERATELY LEFT ALONE. `gap: 1rem` is the spacing *between* the
   rows inside the card, which nothing asked about -- tokenising it to --space-s
   would have made it fluid to 24px at a wide viewport and loosened the rows as
   a side effect of a border change. And `height: fit-content` is load-bearing:
   this is a flex item of `.sidebar`, whose default `align-items: stretch` would
   otherwise run the card down to the full height of the form beside it.

   The old `line-height: 1.5` is gone as a no-op -- css-reset.css sets exactly
   that on <body> and it inherits as a unitless number, so it was restating what
   it was already getting. */
.support-info {
  display: flex;
  flex-direction: column;
  gap: 1rem;
  height: fit-content;
  padding: var(--space-s);
  border: var(--border-width-regular) solid var(--neutral-border-soft);
  border-radius: var(--radius-md);
  background-color: var(--neutral-bg);
  box-shadow: 0 var(--shadow-y-offset) var(--shadow-blur) 0
    var(--shadow-regular);
}

/* The panel title row -- the headset icon and the "Support Info" string.
   Joy, 2026-10-25: "Can we adjust the support info side panel to have similar
   styles to the search results side panel? So Support Info would have a larger
   font size, and then the text below would have the slightly darker shade."

   The nested `p` IS `.ais-header` (css-page-search-results.css:457) declaration
   for declaration, which is what makes this the search panel's title rather
   than something that merely looks bigger: --step-3 (~20px, the frame's
   `heading/xs` at 19px rounded to the nearest step), --ff-logo, --font-bold,
   --leading-heading-3, --neutral-text. Only the size changed by much -- it was
   --step-2, ~17.7px -- but the typeface did too, body font to Sora, which is
   the more visible half of it.

   NOT SHARED WITH `.ais-header`, and not because sharing was overlooked.
   .ais-header is the vendor widget's own element, so a shared selector would
   have to be a class the Algolia bundle does not put there; and .ais-header
   carries 0.5rem of inline padding that exists only to line its title up with
   the inset text of the facet rows below it. There are no inset rows here, so
   that padding would read as a title pushed 8px off the card's left edge while
   everything under it stayed put. Four declarations restated beats a shared
   rule with a fifth that has to be undone.

   The explicit --neutral-text is load-bearing now rather than decorative: the
   container below sets soft ink on the whole card, so without this the title
   would inherit it and the two tiers would collapse back into one. */
.support-intro {
  display: flex;
  align-items: center;
  gap: 0.5rem;
  flex-wrap: wrap;
  p {
    color: var(--neutral-text);
    font-family: var(--ff-logo);
    font-size: var(--step-3);
    font-weight: var(--font-bold);
    line-height: var(--leading-heading-3);
  }
}

/* ONE COLUMN, which is Joy's own answer to the defect she found. 2026-10-25,
   with a screenshot of the card at full width: "can we make the text align?
   I.e. Europe, Middle East, and Africa are positioned higher up than the
   others. The simplest might just be to have all of them in a column."

   WHAT WAS ACTUALLY WRONG, because the symptom is not where the cause is. This
   was `flex-wrap: wrap` plus `align-items: center`. The two short region blocks
   fit side by side once the card is wide enough, and `center` then aligns them
   on their *middles* -- so "North America and LATAM", with one phone number,
   sat half a row lower than "Europe, Middle East, and Africa", with two. The
   headings were never out of line with each other by any amount anyone chose;
   they were out of line by half the height difference between the two blocks,
   which is why it reads as arbitrary.

   `align-items: flex-start` would have aligned the headings and left the
   two-across layout. Joy asked for the column and the column is the better
   answer anyway: it is what the card already looks like in the sidebar, so one
   direction serves both widths and the two renders stop disagreeing. Three
   headings in a row down the left edge is also the shape the request page's
   panel has.

   NO MEDIA QUERY, and that is not laziness. The card goes full width when
   `.sidebar` wraps (css-utilities.css:66), and `.sidebar` wraps on its own
   flex-basis arithmetic -- there is no breakpoint to hang a query on, and the
   width this happens at moves with the content column's minimum. A rule that
   holds at every width is the only kind that can be right here.

   `align-items` and `flex-wrap` are both GONE rather than reset. Stretch is the
   default and is what the full-width children want; `flex-wrap` in a column
   with no height constraint has nothing to wrap into, and `.support-info` is
   `height: fit-content`, so it would never gain one. Leaving either in place
   would read as a decision when it was only a leftover.

   --neutral-text-soft is the second tier, set once here and inherited by the
   intro paragraph and all three region blocks. It is the colour the facet rows
   take (css-page-search-results.css:573-ish, where the `#algolia-categories`
   prefix exists to defend it against the vendor's injected full-ink rule).

   WORTH CHECKING IN PREVIEW, because Joy described this as "the slightly
   darker shade" and in light mode it is the LIGHTER of the two roles --
   #4f5f63 against --neutral-text's #10171e. The reference she named is not
   ambiguous, so the panel takes the value that panel actually uses; if what
   she was after was a step toward the ink rather than away from it, this one
   declaration is the whole change.

   It is also a dark-mode fix that was missed in this round's first pass. These
   paragraphs had no `color` anywhere in the theme -- not even a --clr-* to
   convert -- so they were inheriting whatever Zendesk's injected base
   stylesheet sets from the `color_text` setting, which is one configured value
   in both themes. Naming a role here puts them on #4f5f63 light and #b2c3d2
   dark and takes the last uncoloured text in this card off a single-value
   source. */
.support-text {
  display: flex;
  flex-direction: column;
  gap: 1rem;
  color: var(--neutral-text-soft);
  font-size: var(--step-0);
}

.support-location {
  display: flex;
  align-items: flex-start;
  flex-direction: column;
  gap: 0.5rem;
  p {
    font-size: var(--step-1);
    font-weight: var(--font-bolder);
  }
}

.support-meta {
  display: flex;
  align-items: center;
  gap: 0.5rem;

  p {
    font-size: var(--step-0);
    font-weight: var(--font-regular);
  }
  /* --neutral-text-soft, matching the rest of the card below the title. This
     was --clr-neutral-160 (#333333) before this round -- a primitive with one
     value in both themes, so these phone numbers stayed near-black on a dark
     card -- and briefly --neutral-text earlier the same day, before Joy asked
     for the search panel's two tiers.

     An explicit colour is required here even though `.support-text` already
     sets this value: css-reset.css:442 gives every `a` --hyperlink-link, which
     beats inheritance. So this is not a restatement, it is the only way the
     links join the tier.

     SAY SO IF THIS GOES TOO FAR. A `tel:` link with no underline and the same
     ink as the prose beside it has nothing left marking it as a link, and the
     facet rows this is copied from do not have that problem -- they have a
     checkbox and a hover state doing the marking. Putting --neutral-text back
     on this one declaration separates the numbers from the prose again without
     touching the rest of the card.

     `text-decoration: none` is deliberate and unchanged: the number reads as
     the card's content and the whole row is the affordance. It still gets the
     sitewide --form-focus-ring on :focus-visible from css-reset.css, so it is
     not an unmarked target for a keyboard user. */
  a {
    text-decoration: none;
    color: var(--neutral-text-soft);
  }
}

/* `.support-request` AND `.request-form` WERE HERE and both were dead -- no
   template and no form bundle carries either class. The only matches for
   "request-form" anywhere in the theme are the `new-request-form` id on
   new_request_page.hbs:168 and the bundle's import name in document_head.hbs,
   neither of which this selector reaches. Between them they were setting
   `flex: 1 1 65%` and a 3rem flex column with a 3rem top margin, i.e. the
   two-column split and the form's own rhythm -- which is worth knowing, because
   it means neither has ever been what produced the layout on this page. The
   split is `.sidebar` (css-utilities.css) and the form's spacing is Garden's.

   The same sweep removed `div.suggestion-list`, `#new .optional`, the six
   `.nesty-*` rules and `.hc-multiselect-toggle`; each is noted where it was. */

.form-field,
[data-garden-id='forms.field'] {
  display: flex;
  flex-direction: column;

  /* --neutral-text and --critical-text, where these were --clr-neutral-160 and
     --clr-alert-60 -- two primitives with one value each in both themes. This
     rule reaches four controls across three pages (see the note below), and the
     requests page's two filter labels were #333333 in dark mode along with this
     page's, so the role is a fix on both, not a preference.

     --critical-text (#9d070a light, #fc9c9e dark -- this note said #f65154 for
     the dark value until 2026-10-25, which is --critical-border's, not this
     one's) rather than --critical-icon for the required asterisk: this is a
     text glyph in a run of label text, and
     the -text role is the one Codex contrast-checks against the page, where
     -icon is tuned for a shape at icon size. The same role is used for the
     field messages and the `::after` asterisks below, so all three required
     markers on this form finally agree. */
  label {
    display: flex;
    gap: 0.15rem;
    color: var(--neutral-text);
    line-height: 1.1;
    font-size: 1rem;
    font-weight: var(--font-regular);

    span[aria-hidden='true'] {
      color: var(--critical-text);
    }
  }

  /* The text field's appearance moved to css-components.css's "shared form
     controls" section on 2026-10-24, so that it and the request page's comment
     field are one control rather than two that happened to look similar. The
     layout rules above stay here: `.form-field` is also the header's search
     field and the two requests page filters, which that section's header
     explains at length. */
}

/* THE RULE ABOVE DOES NOT REACH GARDEN'S OWN LABELS, which is why "Subject" was
   illegible in dark mode while "Country" directly below it was fine. Both are
   nominally coloured by this file, and the difference is `!important`: Garden is
   CSS-in-JS and injects a style element at runtime carrying its own label
   colour, a mid-grey that disappears on a dark surface. The combobox label rule
   further down has always had `!important` and won, so the <select>-style fields
   were legible; `.form-field label` does not and lost on every text field.

   Two ways to beat it and this is the narrower one: name Garden's own label
   element, which the bundle gives `data-garden-id="forms.input_label"`
   (assets/shared-bundle.js), rather than putting `!important` on the shared
   `.form-field label` rule and pushing it onto the header's search field and
   the requests page's filters as well.

   Colour only. The layout, size and weight still come from `.form-field label`
   above, because those were never in dispute -- Garden's injected rule sets the
   colour and this is the one declaration that has to outrank it. */
label[data-garden-id='forms.input_label'] {
  color: var(--neutral-text) !important;
}

/* THE REQUIRED STAR, and the rule above is why it needed its own. Joy,
   2026-10-25: "the required star is not red in either theme."

   WHAT WAS HAPPENING. Garden puts the marker in a `span[aria-hidden='true']`
   inside the label -- confirmed on the live form, where a console pass found
   that span present on exactly the three required fields and absent on
   Attachments, which is what proved the five hardcoded `::after` asterisks
   this file used to carry had never matched anything. The span has no colour
   of its own, so it inherits the label's. And the label's colour is
   `!important` on the two rules that have to beat Garden's runtime style --
   this one and the combobox label further down. So both labels were handing
   their star --neutral-text, and `.form-field label span[aria-hidden='true']`
   above could not take it back: it is (0,2,2) with no `!important`, and
   `!important` is not something specificity beats.

   Inheritance was never the problem the other way round, which is worth being
   clear about -- a child's own declaration beats an inherited value whatever
   the parent's importance. The problem is that this child has no declaration
   unless a selector reaches it, and the one above reaches `.form-field label`
   and `[data-garden-id='forms.field'] label`, neither of which is an ancestor
   of the combobox's label.

   NAMING GARDEN'S TWO LABEL IDS rather than putting `!important` on the shared
   `.form-field label span` rule, for exactly the reason the note above gives
   for `forms.input_label`: that rule also reaches the header's search field
   and the requests page's two filters, and none of them should inherit an
   `!important` they do not need.

   --critical-text, the same role the field messages and the old `::after`
   asterisks used, so all the required markers on this form agree. #9d070a in
   light and #fc9c9e in dark.

   CODEX'S DARK RENDER DISAGREES AND WE ARE NOT FOLLOWING IT. In the Input
   documentation (Figma node 19743:3116) the light `Email *` star samples at
   #9d070a -- --critical-text exactly, which is how the role was settled -- but
   the dark one samples neutral white, the same ink as the label beside it.
   That is the same class of Figma-side divergence the dark tier has shown
   before: that frame also paints the dark label pure #ffffff, where the
   shipped tier's --neutral-text is #ebf0f4 and nothing in it puts pure white
   on text. Joy asked for the star to be red in BOTH themes, and the role
   already has a dark value tuned for a dark surface, so the dark tier gets the
   role rather than the render. */
label[data-garden-id='forms.input_label'] span[aria-hidden='true'],
[data-garden-id='dropdowns.combobox.label'] span[aria-hidden='true'] {
  color: var(--critical-text) !important;
}

/* THE ASTERISK IN THE LEGEND, the third of the three markers on this form and
   the last one to go red. Joy, 2026-10-25, on "Fields marked with an asterisk
   (*) are required.": "This asterisk needs to be red."

   --critical-text, the same role as the two label rules above, because this
   line is the legend that explains them -- a legend in a different red from the
   thing it describes would be worse than one in body ink.

   `.kb-required-asterisk` IS OURS AND IT HAS TO BE. The line is a single text
   node inside an `aria-hidden` Garden paragraph with no id on anything in it,
   so there was no element to select; assets/required-fields-asterisk.js puts
   one round each `*` and that file's header explains why it splits on the
   character rather than on the English. No `!important`: this element is not
   Garden's, so nothing is injecting a colour for it at runtime. */
.kb-required-asterisk {
  color: var(--critical-text);
}

div[data-garden-container-id='typography.font'],
div[data-garden-container-id='containers.field.message'] {
  color: var(--critical-text);
}

div[data-garden-container-id='containers.field.message'] {
  padding-inline-start: 0;
  margin-block-start: 0.25rem !important;
  font-size: var(--step--1);
}

div[data-garden-container-id='containers.field.message'] svg {
  display: none;
}

[dir='rtl'] input,
[dir='rtl'] input::placeholder {
  text-align: end;
}

/* SEVEN CKEDITOR RULES WERE HERE and all seven are now one set of class-based
   rules in css-components.css's "shared form controls" section, shared with the
   request page's comment editor -- which had three more chains of the same
   shape. The longest of them was
   `div[data-garden-container-id='containers.forms.field'] >
   div.form-field.text.required.request_description >
   div.ck.ck-reset.ck-editor.ck-rounded-corners > div.ck.ck-editor__main > div`,
   which encodes the field's Zendesk form type, its required flag and its
   field name as well as the editor's DOM: it stops applying if this ticket
   form is ever reconfigured so the description field is optional.

   Also gone with them:
     - `#ck-editor__aria-label_e8745377db4b325db6fbbb61174019c70`, a CKEditor
       runtime-generated id hardcoded into a selector. That hash is per build,
       so this rule had almost certainly already stopped matching anything.
     - A commented-out four-selector block that zeroed CKEditor's focus
       outlines. The shared section states the focus treatment once, on the
       shell, so there is nothing left for it to undo.
     - `.ck.ck-content.ck-editor__editable.ck-focused`, which drew the 2px
       orange focused border. Focus is --form-focus-ring from css-reset.css
       now, on the shell rather than on the editable inside it.

   NOTE THAT THESE RULES WERE ALL UNSCOPED, so every one of them was also
   reaching the request page's editor and winning ties against
   css-page-request.css's own chains on specificity. That is the main reason
   neither page's editor looked the way its own stylesheet said it should. */
/* `div.suggestion-list { display: none }` WAS HERE and was dead: no template
   and none of the three form bundles -- new-request-form, shared, ticket-fields
   -- contains the string "suggestion-list" anywhere. The live equivalent is
   `[data-test-id='suggested-articles']` further down, which is what actually
   hides Zendesk's article suggestions on this form. */

/* THE FIVE HARDCODED ZENDESK FIELD IDS ARE GONE, 2026-10-25, and with them the
   duplicate required-marker mechanism they drew. Three blocks went together:
   the `::after` asterisks, the five matching `#request_*_error` colours, and
   `#request_description_hint` below.

   WHAT SETTLED IT. The ids are built at runtime from the live form, so they
   were in no bundle and no template and a grep proved nothing either way -- the
   only thing that could answer it was a reading of the rendered labels, which
   Joy took on 2026-10-25:

     {text: 'Subject*',          id: '1--label',    gardenSpan: true,  afterStar: 'none'}
     {text: 'Description*',      id: '2--label',    gardenSpan: true,  afterStar: 'none'}
     {text: 'Rich Text Editor',  id: 'ck-editor__label_e7344bb...',    afterStar: 'none'}
     {text: 'Requester Country*', id: 'id:2--label', gardenSpan: true,  afterStar: 'none'}
     {text: 'Attachments',       id: '5--label',    gardenSpan: false, afterStar: 'none'}

   Two things in that, and the second matters more. `afterStar` is `none` on
   every label, so this block was drawing nothing -- but the ids are what
   explain why: `1--label`, `2--label`, `id:2--label`, `5--label`. That is the
   React form bundle's own scheme, keyed to the field's position in the form.
   `#request_subject_label` is the LEGACY Zendesk form's scheme, the same
   generation of markup as `.nesty-input` and `#upload-dropzone`, and the
   component that renders this page cannot produce those ids at all. So it was
   not that these five fields happened to fall outside the list -- the list
   could not have matched any field on this form.

   AND THE MARKERS WERE ALREADY RIGHT WITHOUT IT. `gardenSpan` is true on
   exactly the three required fields and false on Attachments: Garden's own
   `span[aria-hidden='true']`, following the ticket form's real required flags,
   styled by the `.form-field` rule above, and immune to the form being
   reconfigured. Every asterisk in Joy's screenshots was its work. Two of the
   five deleted ids were custom fields (1500005949862 and 360008875173) whose
   ids are Guide configuration rather than code, so this takes the last
   configuration values out of the theme's CSS.

   THE ERROR BLOCK WENT WITHOUT A READING OF ITS OWN because an id-free rule
   already covers it: `div[data-garden-container-id='containers.field.message']`
   above colours every Garden field message --critical-text, for every field on
   the form rather than five named ones. Same for the hint, see below. */

/* The hint line under a field, on Garden's own id rather than the
   `#request_description_hint` this replaces -- so it reaches every field with a
   hint instead of the one the legacy id named, and it cannot stop matching when
   the form is reconfigured.

   --neutral-text-soft, not --neutral-text: Codex renders a hint as
   de-emphasised text beside its control. The old rule had --clr-neutral-160
   (#333333), which read as body copy and had no dark tier.

   `max-width: fit-content` came off with the id. On a single named hint it kept
   the line from running the full width of the form; on Garden's hint, which is
   a block inside the field container and already has the control's width, it
   would shrink-wrap the text and defeat wrapping on a long one. */
[data-garden-id='forms.input_hint'] {
  font-size: var(--step-0);
  color: var(--neutral-text-soft);
}

/* THE LAST TWO LEGACY SELECTORS, AND THEY SURVIVED THE 2026-10-25 SWEEP ON
   PURPOSE. Everything the reading above indicts applies to these as well: the
   first is the same `#request_custom_fields_<id>_*` scheme the React bundle
   cannot produce, and the second encodes the legacy form's field type and
   required flag in `div.form-field.text.required.request_description`, which is
   a class list Garden does not emit either. On the evidence both are dead.

   WHAT MAKES THEM DIFFERENT IS THE DECLARATION, not the selector. These two
   rules HIDE things. Deleting a dead rule is a no-op by definition, but the
   cost of being wrong is not symmetric: if either one does match on some render
   this file has not seen -- a signed-out visitor, or a form Zendesk serves as
   legacy markup, which it demonstrably still does for the upload box -- then
   deleting it makes hidden markup appear on a page Joy has already signed off.
   A dead colour rule costs nothing to leave; a live `display: none` costs a
   visible regression to remove. So the three colour blocks went on the reading
   and these two wait for a reading of their own.

   WHAT WOULD CLOSE THEM: whether either selector matches anything on the live
   form, and if so what it is hiding. The second is the more interesting of the
   two -- `div:nth-child(4)` inside the description field is positional, so
   whatever it was written to hide is identified by nothing but its place in a
   DOM Zendesk generates, and it would be worth knowing what that element is
   before trusting the rule in either direction. */
#request_custom_fields_360008875173_hint {
  display: none;
}

#new-request-form
  > div.form-field.text.required.request_description
  > div:nth-child(4) {
  display: none;
}

/* `#new .optional { display: none }` WAS HERE and could never have matched:
   there is no `id="new"` on any element in any template in this theme. The
   descendant selector needs that ancestor, so whatever markup it was written
   for -- a much older Zendesk form, presumably -- has been gone long enough
   that the id went with it. Note that `.optional` itself is NOT dead; the
   category and section pages both use it, which is why the grep looks live
   until you check the ancestor. */

/* BOTH UPLOAD BOXES moved to css-components.css's "shared form controls"
   section -- `{{upload}}` renders here and inside the request page's comment
   form, and Zendesk renders it as either the Garden component or the older
   `#upload-dropzone` markup, so that section now carries both names with one
   recipe taken from Codex's own fileUpload component.

   What was here: a 1px --clr-neutral-40 solid box on --clr-white with a 4px
   radius, plus `#upload-dropzone > span` bumping the prompt to --step-1 and
   bolding its link. Two things made it have to move rather than sit alongside
   a shared copy. Garden is CSS-in-JS and these declarations need !important to
   beat the style element it injects at runtime, and two !important rules on one
   property are settled by load order, which this file would have won
   (document_head.hbs:226 against :220). And the solid border was never the
   Codex treatment: a drop target is dashed, which the old rule had dropped. */

/* ---- Submit ----
   THIS IS `.btn.btn-submit`, RESTATED. Joy picked that treatment on 2026-10-25
   over recolouring the old rectangle, so this button is now the same control as
   the request page's Submit (css-buttons.css:330) and agrees value for value
   with the header's primary pill (css-page-header.css:1559) and the footer's
   CTA (css-page-footer.css:407). Brand gradient, Sora at --step-0/600, the
   --radius-round pill, 0/1.25rem padding, 2.5rem tall.

   RESTATED RATHER THAN SHARED, AND THAT IS A COST WORTH NAMING. Two things make
   it unavoidable:

     - THERE IS NO MARKUP HOOK. The request page's Submit is
       `{{input type='submit' class="btn btn-submit"}}` and can simply carry the
       classes. This one is rendered by the React bundle --
       `jsx(I, {isPrimary: true, type: "submit", ...})` in
       new-request-form-bundle.js, where `I` is a Garden Button -- so there is no
       template to add a class to.
     - EVERY DECLARATION NEEDS `!important`, because Garden is CSS-in-JS and
       injects its own primary-button colours, radius, padding and 40px height
       at runtime. `!important` cannot go into shared `.btn`: that rule reaches
       every button in the theme, and css-buttons.css's own header warns at
       length that the variants below it win on load order, which an
       `!important` base would silently break.

   SO THESE DECLARATIONS MUST TRACK css-buttons.css BY HAND. If `.btn` or
   `.btn-submit` is retuned, this block is the second place to change, and there
   is no cascade that will catch it for you. The grep is `--brand-gradient-r-
   hover`, which only the brand-filled controls use.

   The second selector is the legacy non-React form's `<input type='submit'>`.
   Kept because the React bundle is what renders today but Zendesk owns that
   choice, and it costs one selector to stay correct if it ever falls back.

   WHAT CAME OFF, four legacy primitives and the last --clr-* in this file:
   --clr-white on --clr-primary-100 (#ef4623, the pre-refresh brand orange),
   going to -120 and -140. None of the four has a dark tier, so this was the one
   control on the page still frozen light after the rest of the round.

   `:focus-within` IS GONE from the pressed state. It used to share the -140
   fill with `:active`, so the button looked held down for as long as it had
   focus -- after a click, until you clicked elsewhere. Focus is
   --form-focus-ring from css-reset.css, same as every other control here.

   `display: inline-flex` with both axes centred, where the old rule set
   inline-flex and left the label to `line-height: 1.5` inside an unset height.
   With a fixed 2.5rem box and --leading-control (1), centring has to be stated
   or the label sits on the top edge.

   The disabled state is .btn's, lifted rather than invented -- Garden disables
   this button while the form is incomplete, and without it a disabled Submit
   looks exactly like a live one. Codex has no disabled roles in the token dump
   (css-buttons.css:170 explains), so this is the theme's convention. */
#new-request-form > footer > input[type='submit'],
#new-request-form button[type='submit'] {
  margin-top: 0;
  display: inline-flex !important;
  align-items: center !important;
  justify-content: center !important;
  height: 2.5rem !important;
  padding: 0 1.25rem !important;
  border: 1px solid transparent !important;
  border-radius: var(--radius-round) !important;
  color: var(--fixed-white) !important;
  background-color: var(--brand-bg) !important;
  background-image: linear-gradient(
    90deg,
    var(--brand-gradient-l-hover) 0%,
    var(--brand-gradient-l-hover) 33.333%,
    var(--brand-gradient-r-hover) 66.666%,
    var(--brand-gradient-r-hover) 100%
  ) !important;
  background-size: 300% 100% !important;
  background-position: 100% 0;
  font-family: var(--font-family-primary), system-ui, sans-serif !important;
  font-size: var(--step-0) !important;
  font-weight: var(--font-weight-strong) !important;
  line-height: var(--leading-control) !important;
  text-align: center;
  text-decoration: none !important;
  transition:
    background-position var(--motion-duration-slow) var(--ease-in-out),
    background-color var(--motion-duration-control) var(--ease-in-out),
    border-color var(--motion-duration-control) var(--ease-in-out),
    color var(--motion-duration-control) var(--ease-in-out);

  &:hover:where(:not(:disabled, [aria-disabled='true'])) {
    background-color: var(--brand-gradient-r-hover) !important;
    background-position: 50% 0;
    cursor: pointer;
  }

  /* Press is immediate, release settles back over the base rule's 0.6s --
     .btn's own behaviour and its comment explains the asymmetry. */
  &:active:where(:not(:disabled, [aria-disabled='true'])) {
    background-color: var(--brand-gradient-r-active) !important;
    background-position: 0 0;
    transition-duration: var(--motion-duration-instant);
  }

  &:disabled,
  &[aria-disabled='true'] {
    cursor: not-allowed;
    opacity: 0.4;
  }
}

/* ---- The Garden combobox ----
   Every <select>-style field on this form -- Country, Product, and the rest of
   the ticket form's dropdowns. On Codex's terms it is the same control as the
   text field, so it takes the same form roles the shared section's text field
   does (css-components.css, "shared form controls"), state for state:
   --form-border and --form-bg resting, --form-bg-hover on hover with the
   border held, --form-border-active and --form-bg-active once it is taking
   input, and the sitewide --form-focus-ring for the keyboard ring.

   WHY THESE RULES STAY HERE rather than joining that shared section: the
   combobox exists on this page only, and every declaration needs `!important`.
   Garden is CSS-in-JS and injects a style element at runtime, which specificity
   cannot outrank -- and two `!important` rules on one property are settled by
   load order, which this file wins (document_head.hbs:226 against :220). So
   moving them would make them lose to nothing and win against nothing, for no
   gain.

   WHAT THE ROLES REPLACE, and all three were primitives with one value in both
   themes, so this control's whole border story was frozen light:
     - --clr-neutral-40 (#c2c2c2) resting -> --form-border (#809094 light,
       with a dark tier).
     - --clr-neutral-160 (#333333) hover -> --form-bg-hover, as of 2026-10-25.
       It was --form-border-active until then, on the grounds that it matched
       the text field's hover border -- which it did, and both were wrong
       together. See the fill note on the rule below.
     - --clr-primary-100 (#ef4623) focus, plus `border-width: 2px` and the
       orange --box-shadow halo. That is gone, not re-coloured: css-reset.css
       already gives every focusable element a --form-focus-ring outline on
       :focus-visible, so this pins the offset and nothing else -- the same
       thing the shared text field does, and for the same reason. The old rule
       also shifted the control by 1px on focus by growing its border.

   THE RING IS `:focus-visible` AND THE FILL IS `:focus-within`, which reads
   like a contradiction and is not. This block used to say `:focus-visible`
   ALONE, where the original had `:focus-within, :focus-visible` on one
   selector -- and dropping `:focus-within` was right for the RING, because the
   trigger wraps an <input> and so `:focus-within` fires on mouse clicks as
   well as keyboard focus, which is what an outline is deliberately not for.
   But the FILL has the opposite requirement: it has to respond to the inner
   input taking focus however the focus arrived, or a clicked-into dropdown
   sits there with a resting fill. Two states, two selectors, one control.

   `transition` keeps a property list -- `transition-duration` on its own, which
   several rules in this file used to carry, animates nothing. */
[data-garden-id='dropdowns.combobox.trigger'],
[data-garden-id='dropdowns.combobox.trigger'] input,
[data-garden-id='dropdowns.combobox.trigger'] * {
  font-size: 1rem !important;
}

/* THE FILL WAS MISSING AND THAT WAS THE WHOLE DEFECT. Joy, 2026-10-25: "in
   dark mode the Requester Country field keeps the white background". The rule
   below used to set `border-color` and nothing else, on the reasonable-looking
   assumption that the border was the only thing Garden got wrong. It was not:
   Garden's runtime style element paints this trigger a single-value white, so
   with no `background-color` of ours to beat it the field stayed white while
   every text field beside it went dark. The border flipped and the fill did
   not, which is exactly the shape of defect this whole branch exists to fix,
   reproduced in miniature by a rule I wrote.

   FOUR DECLARATIONS, NOT ONE, because a surface is a fill, an ink and a
   border: --form-bg, --neutral-text and --form-border, the same three the
   shared text field takes in css-components.css. `color` has to be stated
   even though the label above it is already handled -- the trigger wraps an
   <input> whose value text is Garden's to colour.

   HOVER HOLDS THE BORDER AND SPENDS THE FILL, changed 2026-10-25 to match the
   Input component's state table; the long note on the text field's hover rule
   in css-components.css has the table and the reason. This rule and that one
   were wrong in the same direction, so they are corrected together.

   `!important` ON EVERY DECLARATION for the reason the block header gives:
   Garden is CSS-in-JS and specificity cannot reach a runtime style element. */
[data-garden-id='dropdowns.combobox.trigger'] {
  border-color: var(--form-border) !important;
  background-color: var(--form-bg) !important;
  color: var(--neutral-text) !important;
  transition:
    border-color var(--motion-duration-control) var(--ease-in-out),
    background-color var(--motion-duration-control) var(--ease-in-out);

  &:hover {
    background-color: var(--form-bg-hover) !important;
    box-shadow: none !important;
  }

  /* `:focus-within`, not `:focus-visible`, for the fill only. The trigger is a
     wrapper around the <input> that actually takes focus, so the fill has to
     respond to the inner element's focus or the control looks unfocused while
     its ring is drawn. The RING stays on `:focus-visible` below, where it
     belongs -- that is the keyboard-only affordance and the block header
     explains why this control must not draw it on a mouse click. */
  &:focus-within {
    border-color: var(--form-border-active) !important;
    background-color: var(--form-bg-active) !important;
  }

  &:focus-visible {
    --outline-offset: 2px;
  }

  /* ---- Invalid ----
     Joy, 2026-10-25: "are you able to implement codex invalid states with the
     red backgrounds, borders, and box shadow?" The same three roles the shared
     text field takes in css-components.css, whose note has the Figma reading
     and the `glow/error` effect behind the shadow.

     `:has(input[aria-invalid='true'])` AND NOT `[aria-invalid='true']`, because
     this control's invalid flag does not land on the element that shows it. The
     trigger is a <div>; the attribute goes on the <input> inside it, set by
     Garden's own combobox from the `validation` prop that
     assets/ticket-fields-bundle.js passes to every dropdown it builds. This is
     not a workaround -- it is Garden's own selector. Its runtime theme patch in
     assets/shared-bundle.js registers the string
     `:has(input[aria-invalid="true"])` against `dropdowns.combobox.trigger` and
     the plain `[aria-invalid="true"]` against `forms.input`, `forms.textarea`
     and `forms.faux_input`, which is how the two halves of this round's error
     work were told apart.

     THE BOX SHADOW NEEDS ITS `!important` AS MUCH AS THE COLOURS DO. The
     trigger's resting rule above already has to say `box-shadow: none
     !important` on hover, because Garden paints one there; a shadow of ours
     without importance would lose to the same runtime style element. */
  &:has(input[aria-invalid='true']) {
    border-color: var(--form-border-error) !important;
    background-color: var(--form-bg-error) !important;
    box-shadow: 0 0 var(--glow-error-blur) 0 var(--critical-glow) !important;
  }

  /* ---- Disabled ----
     The resting control at half opacity, which is what Codex's disabled field
     is -- the long note on the text field in css-components.css works out why
     its two sampled values are a composite and not a pair of tokens.

     `[aria-disabled='true']` IS THE HOOK AND IT IS THE ONLY ONE. The trigger is
     a <div>, so there is no `:disabled` to match and no `disabled` attribute
     either; Garden's StyledTrigger carries its own
     `&[aria-disabled='true'] { border-color; background-color; color }` block,
     which is both the proof the attribute is there and the thing this rule has
     to outrank.

     THERE IS NO READONLY ROW FOR THIS CONTROL, checked rather than left out.
     Garden gives the faux input an `aria-readonly`, but the combobox trigger
     has no readonly state at all -- its `isEditable: false`, which every
     dropdown on this form uses, is the not-typeable variant and not a readonly
     one. A `:has(input[readonly])` rule would have looked right and fired on
     every dropdown on the page: the combobox renders a hidden
     `readOnly tabIndex=-1 aria-hidden` input of its own as part of its normal
     markup. The shared text field does take the ReadOnly row; it has a real
     attribute to hang it on. */
  &[aria-disabled='true'] {
    opacity: 0.5;
    cursor: not-allowed !important;
  }
}

/* The value text and the chevron, named rather than swept up by the trigger's
   `*` rule above, because they want two different roles and both need
   `!important` to get them.

   THE IDS ARE READ OUT OF THE BUNDLE, NOT GUESSED. shared-bundle.js declares
   twenty-three `dropdowns.combobox.*` ids and the chevron's is `input_icon` --
   there is no `trigger.icon`, which is what this rule said for about ten
   minutes before the bundle was checked. The three used here are
   `dropdowns.combobox.value` (the selected label), `.input` (the editable
   field inside the trigger) and `.input_icon`.

   --neutral-icon on the chevron rather than --neutral-text: it is a shape at
   icon size, which is the distinction that role exists for, and it is what the
   shared file-row and upload rules in css-components.css already use for this
   kind of glyph. `fill: currentcolor` because Garden's icon is an inline SVG
   and some of its paths carry their own fill. */
[data-garden-id='dropdowns.combobox.value'],
[data-garden-id='dropdowns.combobox.input'] {
  color: var(--neutral-text) !important;
}

[data-garden-id='dropdowns.combobox.input_icon'] {
  color: var(--neutral-icon) !important;
  fill: currentcolor !important;
}

/* The combobox's label, beside `label[data-garden-id='forms.input_label']`
   above -- two Garden label elements for two kinds of field, both needing
   `!important` for the same runtime-style reason, both now --neutral-text. This
   one has always had the `!important` and is why "Country" was legible in dark
   mode when "Subject" was not; that note is up with the text-field label rule. */
[data-garden-id='dropdowns.combobox.label'] {
  font-size: 1rem !important;
  font-weight: var(--font-regular) !important;
  color: var(--neutral-text) !important;
  line-height: 1.1 !important;
}

[data-test-id='suggested-articles'] {
  display: none !important;
}

/* NINE `.nesty-*` AND `.hc-multiselect-toggle` RULES WERE HERE and every one of
   them was dead. Nesty is the jQuery nested-dropdown plugin Zendesk's OLD
   help-center form used for hierarchical custom fields, and `.hc-multiselect-
   toggle` is its multi-select sibling. Neither string appears anywhere in this
   theme any more: not in any template, and not in any of the three bundles this
   form actually loads -- new-request-form, shared, ticket-fields. The live
   control that replaced them is the Garden combobox above, which is why that
   block exists at all.

   Worth recording what came out, because between them these rules were a
   complete second dropdown design -- a 0.25rem-radius outlined trigger with a
   chevron drawn as a Font Awesome codepoint in `content:`, a 15rem-max panel,
   and hovered rows filled --clr-neutral-5 -- and all of it was invisible. Two
   of those details would not survive a port even if the markup came back: the
   codepoint cannot render under the kit's SVG+JS mode at all (there is no
   webfont loaded to resolve `\f078`), and the row hover set
   `transition-duration` with no `transition-property`, so it animated nothing.

   `[dir='rtl'] .nesty-input` went with them. The live RTL rule for this form is
   `[dir='rtl'] input` further up, which is not Nesty-specific and stays. */