/*
Theme Name: UCo Child
Template: jupiterx
Version: 1.0.0
Description: Hand-built child theme for utrechtco.nl visual upgrade. CSS-only home for Phase 1+ bug fixes and later phase styling.
Author: UCo / Tom Bosschaert
*/

/* ACTIVE (2026-07-17, Phase 2 Plan 02-01): "UCo Child" is now the live active theme on
   utrechtco.nl. The Phase 1 activation regression (header/logo/nav/footer breaking) was
   root-caused and fixed: it was NOT JupiterX Core's Theme Builder/Raven failing to attach
   (that was never actually in play on this install - live inspection found no
   jupiterx-cpt-tb Theme Builder posts and jupiterx_header_type/footer_type are simple
   empty-string theme_mods driving JupiterX's native PHP header/footer renderer, not a
   Theme Builder template). The real causes were two theme-slug-namespaced WordPress
   settings both needing re-entry under "uco-child": (1) theme_mods_jupiterx's ~150
   header/footer/logo/typography keys, copied wholesale into theme_mods_uco-child; and
   (2) Polylang's own nav_menus option, which maps primary/subfooter menu locations to
   per-language menu IDs PER THEME SLUG (a "jupiterx" entry existed, no "uco-child" entry
   did - Polylang silently fell back to the raw un-language-aware theme_mod nav_menu_locations
   value, serving the English menu on every language). Both are WordPress DB config, not
   files in this repo. Full diagnosis: 02-01-SUMMARY.md.

   This stylesheet is now the single, live CSS home for Phase 1+ bug-fix CSS (BUGFIX-01/02)
   and later phase styling (DESIGN-01 residuals, CF7 restyle). Loaded via wp_enqueue_style()
   in functions.php - no @import, no build step. All fixes append below, one comment-headed
   block per fix (D-04: no Customizer Additional CSS, no snippet plugin). */

/* BUGFIX-01: Homepage "Utrecht Community" H1 (.elementor-heading-title.elementor-size-xxl)
   renders one character per line at mobile widths (<=767px), confirmed via a before-screenshot
   (02-01-evidence/task1-baseline-home-mobile-fullpage-anon.png) and live computed-style
   inspection (02-01-SUMMARY.md). Root cause: the heading widget's own
   .elementor-widget-container carries a desktop-only Elementor style with no responsive
   mobile override - `padding: 0px 700px 0px 0px;` (wp-content/uploads/elementor/css/post-36.css,
   selector `.elementor-36 .elementor-element.elementor-element-5c37bebf > .elementor-widget-container`).
   At <=767px that fixed 700px right-padding exceeds the entire viewport, so the browser's
   block-width algorithm clamps the widget's used content-box width to 0 (CSS clamps negative
   computed widths to zero), and the elementor-size-xxl H1 inside - which correctly inherits
   Elementor's own overflow-wrap: break-word base style - wraps at every single character
   because zero width is "available" to fit any word. Fix: neutralize the oversized padding at
   mobile widths only, scoped tightly to this exact Homepage widget ID so no other heading on
   the site is affected (T-02-04). A defensive overflow-wrap/word-break reset on the heading
   class itself is included as a second line of defense, harmless once the width is restored.

   WARNING for future editors (human or AI, code review WR-02, 2026-07-18): all four selectors
   below are hard-coded to Elementor's auto-generated widget IDs (`elementor-element-5c37bebf`
   on the NL Homepage, post 36, `.elementor-36`; `elementor-element-d73cb04` on the EN Homepage,
   post 6837, `.elementor-6837` - see follow-up note below). These IDs are only stable while
   the current widget instances exist - if a non-technical editor ever deletes and re-creates
   either heading widget in Elementor, it gets a brand-new random ID and this CSS silently
   stops matching (no error, the one-character-per-line bug can silently return). If that
   happens, re-inspect the live widget's `elementor-element-*` class in the page HTML/Elementor
   editor and update the relevant selector pair below to match the new ID. Longer-term,
   consider adding a stable custom CSS class to each widget via Elementor's own
   Advanced > CSS Classes panel (survives ID regeneration) instead of relying on the
   auto-generated ID.

   Follow-up (found live during code-review-fix verification, 2026-07-18, not part of the
   original CR-01/WR-01/WR-02/WR-03 findings): the EN Homepage (post 6837) carries the exact
   same root-cause bug on its own separate H1 widget (`elementor-element-d73cb04`,
   `wp-content/uploads/elementor/css/post-6837.css` has the identical
   `padding:0px 700px 0px 0px;` on its `.elementor-widget-container`). This was NOT caught by
   Phase 2 Plan 02-01 (which only tested the NL Homepage) and was, until this fix, silently
   masked by CR-01's originally-unscoped second selector accidentally also resetting
   overflow-wrap on the EN H1. Once CR-01 was correctly scoped to only the NL widget (per the
   code review), the EN H1's real bug became visible again live
   (utrechtco.nl/en/, confirmed via Playwright at 375px: one-character-per-line rendering,
   "U/t/r/e/c/h/t" stacked vertically). Both selector pairs below are needed together - do not
   remove either language's block. */
@media (max-width: 767px) {
  .elementor-36 .elementor-element.elementor-element-5c37bebf > .elementor-widget-container,
  .elementor-6837 .elementor-element.elementor-element-d73cb04 > .elementor-widget-container {
    padding-right: 0;
  }
  .elementor-36 .elementor-element-5c37bebf .elementor-heading-title.elementor-size-xxl,
  .elementor-6837 .elementor-element-d73cb04 .elementor-heading-title.elementor-size-xxl {
    overflow-wrap: normal;
    word-break: normal;
  }
}

/* PAGES-01 (Phase 2 Plan 02-03): Contact Form 7 residual CSS. Elementor's Theme Style
   (Typography/Buttons/Form Fields, configured in 02-02) already covers ~70% of the visual
   gap via tag-level fallback CSS reaching CF7's plain markup (font/color/background on
   label, input, textarea, button - confirmed live, see 02-02-SUMMARY.md). This block adds
   only what Theme Style does not reach: CF7's own state classes, plus a genuine width bug
   found live on the rebuilt Contact page (PAGES-01, form 7393/7397).

   Width bug (found live, not in RESEARCH.md): CF7 renders every text/email input with a
   hard-coded `size="40"` HTML attribute and Theme Style's Form Fields cascade does not set
   a CSS width, so the browser falls back to size=40's intrinsic character-width (~401px) -
   wider than the 239px-380px column CF7 now lives in on any rebuilt Elementor page. This
   silently overflowed the whole document (confirmed: document.documentElement.scrollWidth
   485px vs. a 375px mobile viewport, before this fix), which is also what corrupted the
   reCAPTCHA badge's own `position: fixed` offset calculation below (Google's script measures
   against document width). Fixing the field width first is the actual root-cause fix; the
   badge reposition rule is kept as a second, defensive line as researched/drafted.

   Scoping note (code review WR-01, 2026-07-18): the field-width override below is scoped to
   the rebuilt Contact page's Elementor post wrapper (`.elementor-42` NL, `.elementor-6841`
   EN - Elementor emits `.elementor-{post_id}` on the page content wrapper, same pattern as
   BUGFIX-01's `.elementor-36` homepage scoping above). Originally unscoped, this rule matched
   every CF7 form sitewide, including any not-yet-migrated WPBakery pages. Live check
   (2026-07-18) confirmed no other live page currently embeds a CF7 form
   (`wpcf7-form-control-wrap` count is 0 on every other page in the sitemap), so this scoping
   is a safety fix for future WPBakery/CF7 pages, not a fix for a live collision found today.
   If Contact Form 7 is ever embedded on another page, add that page's `.elementor-{post_id}`
   wrapper to the selector list below rather than removing the scoping. */
.elementor-42 .wpcf7-form-control-wrap,
.elementor-6841 .wpcf7-form-control-wrap {
  display: block;
  width: 100%;
}
.elementor-42 .wpcf7 .wpcf7-form-control.wpcf7-text,
.elementor-42 .wpcf7 .wpcf7-form-control.wpcf7-email,
.elementor-42 .wpcf7 .wpcf7-form-control.wpcf7-textarea,
.elementor-6841 .wpcf7 .wpcf7-form-control.wpcf7-text,
.elementor-6841 .wpcf7 .wpcf7-form-control.wpcf7-email,
.elementor-6841 .wpcf7 .wpcf7-form-control.wpcf7-textarea {
  width: 100%;
  max-width: 100%;
  box-sizing: border-box;
}
.wpcf7-not-valid-tip {
  color: #b3261e;
  font-size: 0.875rem;
  margin-top: 4px;
}
.wpcf7-response-output {
  border-radius: 4px;
  padding: 12px 16px;
  margin-top: 16px;
}
.wpcf7 form.sent .wpcf7-response-output {
  border-style: solid; /* code review WR-03: declared explicitly, don't rely on CF7's own plugin CSS for this */
  border-width: 2px;
  border-color: #2f6d5c; /* success, Sage Dark - matches CF7's own .wpcf7 form.sent specificity (0,3,0) so this wins over the plugin's default green on source order */
}
.wpcf7 form.invalid .wpcf7-response-output,
.wpcf7 form.unaccepted .wpcf7-response-output,
.wpcf7 form.payment-required .wpcf7-response-output {
  border-style: solid; /* code review WR-03: declared explicitly, don't rely on CF7's own plugin CSS for this */
  border-width: 2px;
  border-color: #b3261e; /* error - matches CF7's own .wpcf7 form.invalid specificity (0,3,0) so this wins over the plugin's default yellow on source order */
}

/* BUGFIX-02 (Phase 2 Plan 02-03, carried from Phase 1): reposition the reCAPTCHA v3 badge
   on mobile so it never overlaps content or the theme's own floating "scroll to top" button
   - reposition only, never hide (Google ToS requires the badge stay visible/functional,
   T-02-07). With the CF7 width overflow above fixed, the badge's own `position: fixed`
   layout is no longer corrupted by document overflow; this rule is kept as the
   already-researched, defensive mobile offset so the badge clears the theme's own
   bottom-right `.jupiterx-scroll-top` button. */
@media (max-width: 767px) {
  .grecaptcha-badge {
    bottom: 80px !important;
  }
}