/* Native HubSpot form styling (roadmap item 3), hand-authored - lives in the
   File Manager, not the Design Manager (same reasoning as hubspot-fixes.css:
   uploading CSS to the Design Manager does nothing at runtime for this theme).
   Scoped to .hs-form-html so it only touches pages that embed a native
   HubSpot form widget.

   v14 rewrite: values are no longer measured px snapshots but the ORIGINAL
   form CSS's own rules, transplanted from the two source files that style
   .form_formframework (in source/site-root/_assets/.../Build/asset/):
   - form.D0eVwuWb.css:      label/input/textarea/select font-size
                             var(--font-3xl-size) / var(--font-3xl-line-height),
                             font-weight 500  (inputs keep this; for labels a
                             later rule wins, see below)
   - zoller-info-form.<hash>.css: label/select font-size var(--font-2xl-size),
                             line-height var(--font-l-line-height);
                             input margin-block 12px, max-height 80px,
                             padding 26px 27px; .form-group margin-bottom 20px
                             (60px at min-width 1260px); checkbox .inputs-list
                             gap 15px (40px at min-width 768px)
   The --font-*-size/-line-height vars are defined on <body> (like
   --content-width) and step with the site's breakpoints (e.g. 3xl = 24px/34px
   desktop, 20px/32px below ~1200), so using them here makes every rule track
   the original at EVERY viewport automatically - the earlier pinned 24px was
   wrong below ~1200 where the original drops to 20px.

   Verified against the raw TYPO3 form on us/company/contact-us (side by side
   on the same page, 2026-07-23) at 1920 / 1280 / 992 / 768 / 600 / 390:
   field width+column gap, row pitch (192px desktop, 172/152 mobile), option
   pitch (68-70 desktop, 43-45 mobile), and button gap (70 desktop, 30
   mobile) all match the raw form.

   HubSpot's newer "Forms 2.0" renderer uses custom-element classes
   (hsfc-*) directly on the field elements - verified live, not inside a
   Shadow DOM, so plain CSS reaches them. Verified class names so far:
   hsfc-TextInput (text/email inputs AND the dropdown's combobox input,
   which carries hsfc-TextInput--button), hsfc-TextareaInput,
   hsfc-FieldLabel (field labels AND each checkbox option's wrapping
   label), hsfc-CheckboxInput, hsfc-Button, hsfc-Row (a 50-track CSS grid
   holding each field row), hsfc-RichText, hsfc-NavigationRow (+ __Alerts /
   __Buttons children). Extend with matching rules as the remaining forms
   in item 3 are built - don't guess class names, verify live first.

   !important is deliberate here, not a shortcut: HubSpot's own bundled
   form stylesheet (injected at runtime as hubspot-form.<hash>.css - not
   something we control or version) uses higher-specificity selectors for
   some of these properties and wins outright ties by loading after this
   file. Verified live 2026-07-20; if HubSpot changes that bundle's
   selectors, re-verify here rather than assuming this still wins. */

/* Container width - align the form with the site's content container at
   EVERY breakpoint, automatically. The site sizes its content blocks with
   `max-width: var(--content-width); margin-inline: auto`, where
   --content-width is defined on <body> and steps through 8 breakpoints
   (350 / 540 / 720 / 960 / 1200 / 1370 / 1524 / 2160). Because that var is
   on <body> it cascades down to .hs-form-html, so we just reuse it.
   Deliberate divergence from the raw form, per customer direction
   2026-07-22: the ORIGINAL form frame instead has padding-inline 90px
   (32px mobile) on a full-bleed frame, which below ~(content-width+180px)
   viewports insets the form MORE than the page's own text (e.g. left 90
   vs content left 33 at 1280) - the content-aligned form is cleaner.
   Harmless for a form inside a column (newsletter's 33-66 cell): the
   column is narrower than --content-width so max-width never bites. */
.hs-form-html {
  max-width: var(--content-width) !important;
  margin-left: auto !important;
  margin-right: auto !important;
  padding: 32px 0 !important;
}
@media (min-width: 992px) {
  .hs-form-html {
    padding: 80px 0 !important;
  }
}

/* Field inputs - the original's exact rules: font 3xl (responsive var),
   weight 500, black text, 12px block margin (this margin is what creates
   the label-to-input gap - labels themselves have no margin), radius 3px.
   Covers text/email inputs, the textarea, and the State dropdown's
   combobox input (also classed hsfc-TextInput). */
.hs-form-html .hsfc-TextInput,
.hs-form-html .hsfc-TextareaInput {
  border-radius: 3px !important;
  font-size: var(--font-3xl-size) !important;
  line-height: var(--font-3xl-line-height) !important;
  font-weight: 500 !important;
  color: #000 !important;
  margin-top: 12px !important;
  margin-bottom: 12px !important;
}

/* The original clamps single-line inputs to 80px (padding 26px + line
   height would exceed it); without this the native input grows to 86px
   at desktop where --font-3xl-line-height is 34px. */
.hs-form-html .hsfc-TextInput {
  max-height: 80px !important;
}

/* Multi-line message textarea - the original gives it a tall fixed
   min-height (240px); HubSpot defaults to auto. */
.hs-form-html .hsfc-TextareaInput {
  min-height: 240px !important;
}

/* Labels - original: font 2xl (responsive var), line-height
   --font-l-line-height (28px), weight 500, black text, no margin (the
   input's own margin-top provides the gap). Also normalizes the phone
   field's label, which HubSpot otherwise renders at 16px, and cascades
   into the checkbox option/consent label spans (they have no font rule
   of their own). */
.hs-form-html .hsfc-FieldLabel {
  font-size: var(--font-2xl-size) !important;
  line-height: var(--font-l-line-height) !important;
  font-weight: 500 !important;
  margin-bottom: 0 !important;
  color: #000 !important;
}

/* Rich text blocks (group headings like "I would like to have/arrange:",
   consent text) - HubSpot renders them 16px gray (rgb(51,71,91)); in the
   original the equivalent texts are labels, so give them the same
   typography. Editors can still vary emphasis inside the form builder's
   rich-text editor. */
.hs-form-html .hsfc-RichText,
.hs-form-html .hsfc-RichText p {
  font-size: var(--font-2xl-size) !important;
  line-height: var(--font-l-line-height) !important;
  font-weight: 500 !important;
  color: #000 !important;
}

/* Vertical rhythm - mirror the original's .form-group model exactly:
   each field carries margin-bottom 20px (60px from 1260px up), rows add
   nothing themselves. HubSpot instead gives fields mb 60 at all widths
   PLUS 20px per row - both overridden here. The hsfc-Row grid keeps a
   60px column gap (the original's two-column gutter) and a 20px row gap
   (the original's extra spacing between the two stacked fields of a
   former pair on mobile - measured on the raw form: 172px pitch within a
   pair, 152px across pairs, exactly mb 20 + row-gap 20 vs mb 20). */
.hs-form-html .hsfc-Row {
  margin-bottom: 0 !important;
  gap: 20px 60px !important;
}
/* hsfc-ReCaptchaV2 is in the list because the captcha badge sits alone in
   its own hsfc-Row - zeroing row margins above removed its only spacing,
   so it gets the same field rhythm. */
.hs-form-html .hsfc-TextField,
.hs-form-html .hsfc-EmailField,
.hs-form-html .hsfc-PhoneField,
.hs-form-html .hsfc-DropdownField,
.hs-form-html .hsfc-TextareaField,
.hs-form-html .hsfc-CheckboxField,
.hs-form-html .hsfc-CheckboxFieldGroup,
.hs-form-html .hsfc-ReCaptchaV2 {
  margin-bottom: 20px !important;
}
@media (min-width: 1260px) {
  .hs-form-html .hsfc-TextField,
  .hs-form-html .hsfc-EmailField,
  .hs-form-html .hsfc-PhoneField,
  .hs-form-html .hsfc-DropdownField,
  .hs-form-html .hsfc-TextareaField,
  .hs-form-html .hsfc-CheckboxField,
  .hs-form-html .hsfc-CheckboxFieldGroup,
  .hs-form-html .hsfc-ReCaptchaV2 {
    margin-bottom: 60px !important;
  }
}

/* Column collapse - the original stacks its two-column rows below 768px;
   HubSpot's grid keeps two columns down to much narrower widths. Flex
   column is used instead of re-templating the grid because the grid is a
   50-track template with span-placed items - forcing 1 column there
   creates implicit tracks. */
@media (max-width: 767px) {
  .hs-form-html .hsfc-Row {
    display: flex !important;
    flex-direction: column !important;
    gap: 20px !important;
  }
}

/* When a native form sits inside a "background" frame variant (the row
   carries the standard sitewide frame-background-* class, e.g.
   frame-background-lightgray on the newsletter signup form), the
   original contrasts its input fields to white instead of the default
   light gray - the same rule the raw TYPO3 form CSS applies
   (.form_formframework.frame-background-lightgray .form-group input).
   Mirror it here for the native equivalent. Add other frame-background-*
   variants below if/when a native form is placed inside one. */
.frame-background-lightgray .hs-form-html .hsfc-TextInput {
  background-color: #fff !important;
}

/* Submit button - HubSpot defaults the button row to the right
   (--hsf-default-navigationrow-buttons-single__justify-content: end, no
   override set anywhere). Left-align sitewide rather than per-form; if a
   later form needs a different alignment, scope that rule to its own
   form-id instead of changing this default. The button itself gets the
   site's .block-button treatment (entry.D_gSzdlH.css): the small chevron
   background icon at 30px with padding-left 45px to clear it, and the
   #e8de00 hover. Font size, colors and radius already match via the
   theme font + Brand Kit. */
.hs-form-html .hsfc-NavigationRow__Buttons {
  justify-content: flex-start !important;
}
/* The extra __Buttons class is needed: HubSpot's own padding rule ties a
   plain .hs-form-html .hsfc-Button on specificity and wins by load order
   (verified live - the background rules won with two classes, padding
   did not). */
.hs-form-html .hsfc-NavigationRow__Buttons .hsfc-Button {
  padding: 15px 30px 15px 45px !important;
  background-image: url("data:image/svg+xml,%3csvg%20xmlns='http://www.w3.org/2000/svg'%20width='8'%20height='10'%20viewBox='0%200%208%2010'%3e%3cpath%20d='M35,27.581V19.405c.014-.926.774-1.184,1.576-.6L43,23.493l-6.424,4.691C35.774,28.765,35.014,28.507,35,27.581Z'%20transform='translate(-35%20-18.493)'/%3e%3c/svg%3e") !important;
  background-repeat: no-repeat !important;
  background-position: 30px 50% !important;
}
.hs-form-html .hsfc-NavigationRow__Buttons .hsfc-Button:hover {
  background-color: #e8de00 !important;
}

/* Space above the button row - the original's gap from the last checkbox
   to the button is 30px mobile / 70px desktop; the field margin above
   (20/60) plus this 10px reproduces both. The empty alerts container
   HubSpot renders above the buttons otherwise adds a stray 20px
   (kept when real validation alerts appear - hence :empty). */
.hs-form-html .hsfc-NavigationRow {
  margin-top: 10px !important;
}
.hs-form-html .hsfc-NavigationRow__Alerts:empty {
  margin-bottom: 0 !important;
}

/* Validation message under a consent/single checkbox renders flush
   against the checkbox row; give it a little air. Deliberately scoped to
   hsfc-CheckboxField only - on text inputs the message spacing is fine
   as-is. */
.hs-form-html .hsfc-CheckboxField .hsfc-ErrorAlert {
  margin-top: 8px !important;
}

/* HubSpot pads the whole form content block by 40px on all sides by
   default (.hsfc-Step__Content { padding: var(--hsf-background__padding,
   var(--hsf-default-background__padding)) }, default 40px, set in
   HubSpot's own runtime-injected :root - not something we control). The
   newer form Style panel exposes NO padding control (only border /
   corner / background color / gradient / image), so this can only be
   changed in CSS. Removed sitewide: with no card background the 40px just
   insets the fields from the column edge for no reason. If a future form
   DOES want the card look, give it padding here scoped to its form-id. */
.hs-form-html .hsfc-Step__Content {
  padding: 0 !important;
}

/* Multi-checkbox group (e.g. Main Contact Form's "I would like to
   have/arrange"). HubSpot's own checkbox is already very close - a 30x30
   box with a 1px black border and white fill - so the deltas vs TYPO3:
   1. square corners (HubSpot rounds to 2px; original is 0),
   2. checked state = black box with a white check. IMPORTANT: HubSpot
      draws its own check via `.hsfc-CheckboxInput:checked::after` (a
      masked checkmark), but ::before/::after DO NOT reliably render on
      an <input> in Chrome - verified live: the ::after computes to
      display:none, so HubSpot's own check is effectively invisible here
      too. So do NOT recolor HubSpot's ::after - instead paint the check
      as a real `background-image` directly on the <input> (backgrounds
      always render on inputs). We use the ORIGINAL's exact material
      check_box SVG (black rounded square with the check knocked out),
      over a white background so the knockout shows white - byte-for-byte
      the original's checked look.
   3. option spacing follows the original's .inputs-list: 15px gap below
      768px, 40px from 768px up (matches the raw form's 43px / 68px
      option pitch),
   4. option text sits 10px from its box like the original (label
      padding-left 40px = 30px box + 10px); HubSpot defaults to 20px.
      Single consent checkboxes keep HubSpot's 20px - the original uses
      20px there too (span padding-left 50px).
   NOTE (not CSS): if a checkbox group shows a duplicate label, that's
   the field's own label plus a separately-added rich-text label in the
   form builder - fix in the form editor, not here. */
.hs-form-html .hsfc-CheckboxFieldGroup__Options {
  gap: 15px !important;
}
@media (min-width: 768px) {
  .hs-form-html .hsfc-CheckboxFieldGroup__Options {
    gap: 40px !important;
  }
}
.hs-form-html .hsfc-CheckboxFieldGroup__Options .hsfc-FieldLabel {
  gap: 10px !important;
}
.hs-form-html .hsfc-CheckboxInput {
  border-radius: 0 !important;
}
.hs-form-html .hsfc-CheckboxInput:checked {
  background-color: #fff !important;
  background-image: url("data:image/svg+xml,%3csvg%20xmlns='http://www.w3.org/2000/svg'%20width='30'%20height='30'%20viewBox='0%200%2030%2030'%3e%3cpath%20d='M31.167,4.5H7.833A3.333,3.333,0,0,0,4.5,7.833V31.167A3.333,3.333,0,0,0,7.833,34.5H31.167A3.333,3.333,0,0,0,34.5,31.167V7.833A3.333,3.333,0,0,0,31.167,4.5Zm-15,23.333L7.833,19.5l2.35-2.35,5.983,5.967,12.65-12.65,2.35,2.367Z'%20transform='translate(-4.5%20-4.5)'/%3e%3c/svg%3e") !important;
  background-size: contain !important;
  background-repeat: no-repeat !important;
  background-position: center !important;
}

/* ---------------------------------------------------------------------------
   Newsletter form card (all four locales)

   TYPO3 renders the newsletter form inside a frame-background-lightgray card
   with the "Newsletter registration" heading INSIDE it, and #F2F2F2 IS
   --color-gray-10, so the variable is the faithful value.

   The card used to come from the form MODULE's style params, which HubSpot
   compiles into a non-responsive
     #hs_cos_wrapper_widget_<id> { padding: 80px 90px !important; ... }
   That stacked with the block padding this file puts on .hs-form-html (the
   card's heading sat 189px below its top edge where TYPO3 has 102px) and kept
   90px inline padding on mobile instead of the original's 32px. The params are
   cleared (scripts/fix_newsletter_card.py) and the card lives here.

   The heading is page content, not form content (ZOMVP-102 follow-up 2026-09-08:
   the copy belongs in the CMS so the page owns it in every locale, and so a
   form can be fields only). It is a textmedia header-frame module sitting in
   its own DnD row directly above the form row, inside the same column as the
   page intro - so the card cannot be painted on the column (the intro would
   turn gray too) and is painted on the two ROWS instead, which render as
   adjacent gapless boxes (measured: row gap 0, no row margins). Row classes
   come from the rows' own rowMetaData.cssClass, which HubSpot renders on the
   row wrapper - no :has() needed.

   Keep the two halves' paddings complementary (top box: top+sides, bottom box:
   sides+bottom) or the card gets a seam. */
.zoller-form-card-top,
.zoller-form-card-bottom {
  background-color: var(--color-gray-10);
}
.zoller-form-card-top {
  padding: 32px 32px 0;
}
.zoller-form-card-bottom {
  padding: 0 32px 32px;
}
@media (min-width: 992px) {
  .zoller-form-card-top {
    padding: 80px 90px 0;
  }
  .zoller-form-card-bottom {
    padding: 0 90px 80px;
  }
}

/* The header frame's <header> carries the site's standard 24px heading spacing.
   With padding-bottom: 0 on the top half that margin collapses OUT of the row and
   becomes a 24px seam between the two halves (measured), and it also pushed the
   first field 24px below the heading where the original has it directly beneath. */
.zoller-form-card-top header {
  margin-bottom: 0 !important;
}

/* Inside the card the form contributes no box of its own: the row halves carry
   the background and padding, and the generic .hs-form-html block padding above
   would otherwise push the fields away from the heading (the original has the
   first label directly under it, measured gap 0). */
.hs-form-html[data-form-id="028a747c-ed4c-4596-b9fe-1a52b651cd78"],
.hs-form-html[data-form-id="fd8d2f66-35eb-4781-a051-8965b535801a"],
.hs-form-html[data-form-id="b210d60d-00ee-4306-9541-7d2534f148ae"],
.hs-form-html[data-form-id="ae130d62-cfba-4ec7-935a-69131e714de6"] {
  padding: 0 !important;
}

/* White inputs inside the card - the original's input contrast on a gray frame
   (the same rule this file already carries for a real frame-background-lightgray
   ancestor). Replaces the module params' input[type=...] rules; checkboxes were
   never in those params, so the checkmark background-image above is untouched. */
.zoller-form-card-bottom .hsfc-TextInput,
.zoller-form-card-bottom .hsfc-TextareaInput {
  background-color: #fff !important;
}

/* ---------------------------------------------------------------------------
   Heading block inside a form (2026-10-01, Automation Days 2026 registration:
   "Which day would you/your team like to participate?")

   TYPO3 renders that question as an <h2> inside the form element
   (zoller-info-form.<hash>.css: .form_formframework .clearfix h2
   { font-size: 42px; line-height: 60px; margin-bottom: 40px }, weight 500 from
   the sitewide h2 rule, fixed size at every viewport). The CRM-built form
   carries it as a RICH TEXT block instead (<p style="font-size:30px"> with an
   Arial span), and the rich-text rule above deliberately normalizes every
   rich text to label typography (20px), so the question renders as a plain
   line. The fix is in the form editor (CRM team): replace that rich-text
   block with a HEADING block at level H2. HubSpot renders it as
   .hsfc-Heading with its own Helvetica / blue-gray defaults (runtime :root
   vars --hsf-default-heading__*), which this rule overrides to the original.
   Verified live 2026-10-01 after the CRM team made the change: HubSpot
   renders <h2 class="hsfc-Heading"> in its own row, already in the site font
   at 42px (T-Star cascades), but line-height 50px, blue-gray text and NO
   margins (the heading row sits flush on the textarea above and the group
   label below). TYPO3 has 121px above the h2 (the field rhythm plus the
   fieldset's own margin) and 40px below: the space above comes from the
   group rule further down (a heading always opens a group), the heading
   itself only carries the 40px below. */
.hs-form-html .hsfc-Heading {
  font-family: inherit !important;
  font-size: 42px !important;
  line-height: 60px !important;
  font-weight: 500 !important;
  color: #000 !important;
  margin: 0 0 40px !important;
}

/* ---------------------------------------------------------------------------
   Form groups (2026-10-01, decided with Paulo: convention over per-form rules)

   TYPO3 wraps parts of a form in <fieldset>s that open with a rule:
     .form_formframework fieldset { border: none;
       border-top: 1px solid var(--color-gray-30); padding-top: 60px; }
   Measured on zoller.info the pattern is the same in every form that has
   them (Contact Us: 2, Automation Days registration: 3, Newsletter: 0):
     1. every heading inside the form opens a group,
     2. the first long-answer field (textarea or checkbox group) opens a
        group, unless a heading already opened one before it,
     3. the consent block opens a group when the form has groups before it
        (a form without groups, like the newsletter, keeps it plain).
   The HubSpot form editor has no fieldset or divider element (image,
   heading, paragraph, reCAPTCHA, data privacy only), so the rules are drawn
   on the HubSpot ROWS that open a group, read from the form's own structure:
   no form ids, a new or reordered form gets TYPO3's grouping by itself.
   Multi-step forms: rows are siblings within a step, so the "before it"
   tests run per step. :has() and :not(<complex>) are 2023+ browser
   features, in line with the rest of this file. */
.hs-form-html .hsfc-Row:has(> .hsfc-Heading),
.hs-form-html .hsfc-Row:has(> :is(.hsfc-TextareaField, .hsfc-CheckboxFieldGroup)):not(.hsfc-Row:has(> :is(.hsfc-TextareaField, .hsfc-CheckboxFieldGroup, .hsfc-Heading)) ~ *),
.hs-form-html .hsfc-Row:has(> :is(.hsfc-TextareaField, .hsfc-CheckboxFieldGroup, .hsfc-Heading)) ~ .hsfc-Row:has(> .hsfc-DataPrivacyField) {
  border-top: 1px solid var(--color-gray-30, #9d9d9d) !important;
  padding-top: 60px !important;
}