/*
 * R3.7Q-047C: Single Insight editorial ordinary Gutenberg image blocks and their native captions.
 *
 * Root cause (proven via live inspection, not assumed): `wp-block-library.css` -- WordPress core's
 * own block-presentation stylesheet, which normally resets `.wp-block-image { margin: 0 0 1em; }`
 * and similar -- is not enqueued on this template at all (confirmed: absent from every stylesheet
 * loaded on a real Single Insight page). With no author-level override, the plain browser default
 * stylesheet's own `figure { margin-inline: 40px; }` (the HTML5 spec default, identical to
 * blockquote/dl) wins, producing the ~40px unwanted inset on each side that R3.7Q-047B measured
 * (confirmed again live here: exactly 40px each side). `<img>` itself carries no width rule at all,
 * so it renders at its own intrinsic/requested size (the `size-large` 1024px `width` attribute)
 * rather than filling its corrected figure. Native `figcaption.wp-element-caption` typography (dark,
 * italic, 16px/1.4/400) comes from Hello Elementor's `reset.css` -- confirmed in R3.7Q-047A, not
 * re-derived here.
 *
 * Scope: single Insight editorial content ONLY (`body.single-insight .fgma-insight-editorial
 * .elementor-widget-theme-post-content`) -- never any other post type, template, or a bare global
 * `figcaption`. `:not(.alignleft):not(.alignright)` excludes intentionally side-aligned images, which
 * keep WordPress's own default alignment behavior untouched. `width: 100%` on both the figure and the
 * image resolves relative to each element's own immediate containing block, so an image inside a
 * `core/columns` pair correctly fills only its own column, never the full article width. The existing,
 * already-correct `.fgma-video__caption` paragraph is a different tag AND a different class, so no
 * selector below can ever match it.
 *
 * No `!important`: plain author-level CSS already outranks the browser's User Agent stylesheet
 * origin regardless of specificity, so overriding the UA `figure` margin needs no `!important` --
 * confirmed live by testing this exact override.
 */

body.single-insight .fgma-insight-editorial .elementor-widget-theme-post-content figure.wp-block-image:not(.alignleft):not(.alignright) {
    width: 100%;
    max-width: 100%;
    margin-left: 0;
    margin-right: 0;
}

body.single-insight .fgma-insight-editorial .elementor-widget-theme-post-content figure.wp-block-image:not(.alignleft):not(.alignright) img {
    width: 100%;
    height: auto;
}

/*
 * Native caption typography/spacing only -- `.fgma-video__caption` (a `<p>`, never a `figcaption`) is
 * structurally excluded by this selector and is never touched.
 *
 * Color/gap match the one already-confirmed-correct native-gray caption on this same site
 * (`.fgma-video__caption`: `color: rgb(148, 148, 148)`, `font-style: normal`, and a real, measured
 * 20px image-to-caption gap) -- Production's own headless frontend renders no comparable inline
 * figure/figcaption markup on any Insight post checked (the primary post, its named native-caption
 * control, and 3 further posts), so this is the most concretely-grounded real reference available,
 * not an eyeballed guess. No FGMA custom-property token resolves to exactly #949494 (checked
 * directly against every `--fgma-*`/`--wp--preset--color--*` custom property in scope), so the
 * literal value the ticket itself specifies is used.
 */
body.single-insight .fgma-insight-editorial .elementor-widget-theme-post-content figure.wp-block-image > figcaption.wp-element-caption {
    font-style: normal;
    color: #949494;
    margin-top: 20px;
}

/*
 * R3.7Q-054B: inline editorial link contract (rest black/red-underline, hover red) -- confirmed
 * live, `reset.css`'s generic `a { color: #c36; text-decoration: none; }` is what's actually
 * rendering (Production's own reported "rose/magenta"); no rule anywhere targets editorial-content
 * anchors specifically. Production's own real technique for this exact context (re-fetched live,
 * not the `.fgma-section-cta` pseudo-element/background-image pattern used elsewhere on this site)
 * is plain native `text-decoration`, confirmed on the same page: rest state is
 * `text-decoration-line: underline; text-decoration-color: rgb(242, 20, 0)` (the brand-red token)
 * with black text; on `:hover` only the text color itself changes to the same brand red, with a
 * `transition: color .3s` declared on the hover rule (byte-for-byte matching Production's own
 * `a:hover{color:...;transition:color .3s}` shape) -- the underline's own color never needs a
 * separate hover declaration, since it is already red at rest.
 *
 * Scoped to the exact selector this task specifies -- `.elementor-widget-theme-post-content a`,
 * never a bare `a{}` -- so Header/Footer/CTA/Team/Projects/Expertise/archive-card/Related-News
 * links and `.fgma-video__caption` (a `<p>`, not an `<a>`, structurally excluded regardless) are
 * completely unreachable. `:focus-visible` is added alongside `:hover` for keyboard-user parity,
 * matching this codebase's own established convention elsewhere (e.g. the Header's GS-HDR-003
 * panel-link hover rule) -- a pure accessibility addition, not a visual change from Production.
 *
 * No `!important`: this selector's specificity, (0,3,1) for the base rule (2 for hover), already
 * exceeds the plain `a{}` reset rule's (0,0,1) outright.
 */
body.single-insight .fgma-insight-editorial .elementor-widget-theme-post-content a {
    color: var(--e-global-color-v4-fgma-black, #000);
    text-decoration-line: underline;
    text-decoration-color: var(--e-global-color-v4-fgma-brand-red, #F21400);
}

body.single-insight .fgma-insight-editorial .elementor-widget-theme-post-content a:hover,
body.single-insight .fgma-insight-editorial .elementor-widget-theme-post-content a:focus-visible {
    color: var(--e-global-color-v4-fgma-brand-red, #F21400);
    transition: color 0.3s;
}

/*
 * R3.7Q-054B: native Gutenberg H3 typography inside Single Insight post-content -- confirmed live
 * via computed-style comparison (Production vs DEV, both "After Graduation: What's Next?" and a
 * linked case-study h3, the two cases this ticket's own audit named): font-size (~28.1px) and color
 * (black) already match; font-family is the real, proven mismatch (`Roboto, sans-serif` on DEV vs
 * `AvenirMedium` on Production -- no rule anywhere in this scope sets it, so it falls to Hello
 * Elementor's own theme default), and line-height is a second real, proven mismatch (DEV's
 * `reset.css` bare-tag default is a 1.2 ratio; Production's real ratio, re-measured this pass, is
 * 1.35 -- the same ratio already established throughout this codebase's other Avenir headings).
 * `font-weight` is intentionally NOT changed: DEV's current numeric 500 already IS the correct
 * token-mapped value for Production's real "AvenirMedium" (this ticket's own `--fgma-weight-medium`
 * mapping) -- Production's own 400 is an artifact of using a dedicated Medium font FILE at
 * browser-normal weight, a mechanism this codebase has no equivalent for, so re-declaring the same
 * 500 explicitly (never leaving it to the generic `reset.css` default it currently, only
 * coincidentally, matches) is the correct fix, not a behavior change.
 *
 * H3 ONLY -- deliberately NOT h2/h4. This post's own top `<h2>` ("From High School to High-Demand
 * Careers...") was checked too (not one of this ticket's two named targets, but adjacent enough to
 * verify): it shares the same font-family defect, but its real Production contract is genuinely
 * different from h3's, not just the same numbers -- font-size ~42.2px (not ~28px) and a ~1.4
 * line-height ratio (not 1.35), re-measured live. Applying this rule's h3-derived values to h2 would
 * leave its size wrong and make its line-height ratio wrong in a NEW way, not fix it. This is a
 * real, separate, pre-existing gap this ticket's own narrow audit never asked to be closed --
 * flagged, not silently fixed, matching this ticket's explicit "do not spend a long audit here."
 * No h4 exists anywhere in this post to verify against, so none is added speculatively either.
 *
 * Scoped to the h3 tag only, inside the post-content wrapper only -- the article H1 (a separate,
 * different element entirely, never inside this wrapper), archive headings (a different
 * template/body-class) and Elementor headings outside post content (a different, unrelated widget
 * type) are all structurally unreachable by this selector.
 *
 * No `!important`: (0,3,0) + 1 for the tag beats `reset.css`'s bare-tag (0,0,1) outright.
 */
body.single-insight .fgma-insight-editorial .elementor-widget-theme-post-content h3 {
    font-family: var(--fgma-font-family);
    font-weight: var(--fgma-weight-medium);
    line-height: 1.35;
}

/*
 * R3.7Q-056: native Gutenberg H2 typography -- the same font-family/line-height defect R3.7Q-054B
 * already proved and fixed for h3, now confirmed for h2 too (two independent posts checked live:
 * this post's own "The physical spaces..." heading, and the earlier "From High School to
 * High-Demand Careers..." heading from R3.7Q-054B's own target post) -- `Roboto, sans-serif` /
 * weight 500 / a 1.2 line-height ratio on DEV, `AvenirMedium` / a 1.4 ratio on Production (a
 * genuinely different ratio from h3's 1.35, re-measured live on both posts, not assumed to match).
 *
 * Unlike the h3 fix, real, byte-identical tokens exist for every value here, not just family/weight:
 * Production's own winning rule (confirmed live, `:where(.base-markdown) h2` /
 * `.base-markdown.text-block h2`) sets `font-size: var(--step-4)` and `margin-bottom: var(--space-
 * xs)` -- both re-checked directly against this codebase's own `--fgma-step-4`/`--fgma-space-xs`
 * custom properties this pass, and both are byte-identical clamp formulas to Production's real
 * `--step-4`/`--space-xs`. Using them here (rather than the h3 rule's font-size-untouched approach,
 * which relied on DEV's WordPress-core default already coincidentally matching) is the more
 * correct fix precisely because it is proven, not coincidental. `margin-top: 0` matches Production's
 * own confirmed value (DEV's un-fixed default was 8px).
 *
 * H2 ONLY -- h3/h4 keep their own separate, already-correct or intentionally-unset rules; this
 * addition cannot affect them. Applying this fix here (the shared editorial file, not a per-post
 * rule) intentionally also corrects the same pre-existing, previously-flagged-but-unfixed h2 defect
 * on R3.7Q-054B's own target post -- that is the intended, in-scope effect of fixing a genuinely
 * shared editorial contract, not a side effect.
 *
 * No `!important`: (0,3,0) + 1 for the tag beats `reset.css`'s bare-tag (0,0,1) outright.
 */
body.single-insight .fgma-insight-editorial .elementor-widget-theme-post-content h2 {
    font-family: var(--fgma-font-family);
    font-weight: var(--fgma-weight-medium);
    font-size: var(--fgma-step-4);
    line-height: 1.4;
    margin-top: 0;
    margin-bottom: var(--fgma-space-xs);
}