/**
 * /developers/ (docs/52). Own file rather than divi-child/style.css: registered/enqueued only on
 * the one page [cs_developer_docs] renders (developer-docs-init.js precedent).
 */

.cs-developer-docs {
	display: flex;
	flex-direction: column;
	gap: var(--cs-space-lg);
	color: var(--cs-text);
	line-height: var(--cs-leading-normal);
}

.cs-developer-docs__title {
	margin: 0;
	color: var(--cs-text-strong);
	font-size: var(--cs-text-3xl);
	line-height: var(--cs-leading-tight);
	letter-spacing: var(--cs-tracking-tight);
}

.cs-developer-docs__lede {
	margin: 0;
	color: var(--cs-text-muted);
	max-width: 65ch;
}

.cs-developer-docs__notice {
	border: 1px solid var(--cs-border-strong);
	border-radius: var(--cs-radius-md, 8px);
	background: var(--cs-surface-panel);
	padding: var(--cs-space-md);
}

.cs-developer-docs__notice p {
	margin: 0;
}

.cs-developer-docs__section h2 {
	margin: 0 0 var(--cs-space-sm);
	color: var(--cs-text-strong);
	font-size: var(--cs-text-2xl);
	font-weight: 700;
	line-height: var(--cs-leading-tight);
	letter-spacing: var(--cs-tracking-tight);
}

.cs-developer-docs__code {
	overflow-x: auto;
	border: 1px solid var(--cs-border);
	border-radius: var(--cs-radius-md, 8px);
	background: var(--cs-surface-sunken);
	padding: var(--cs-space-sm) var(--cs-space-md);
	font-size: var(--cs-text-sm, 0.875rem);
}

.cs-developer-docs__reference {
	border-top: 1px solid var(--cs-border);
	padding-top: var(--cs-space-lg);
}

/* /developers/ is mapped to a Divi Theme Builder body now (CR-10, Simone-Achebe, wp-cli/
   12-theme-builder-bodies.php's `developer-docs` entry) -- one section/row/column/Code module at
   width="92%" max_width="1200px", same as leg-detail/launch-site. It wasn't always: this page used
   to render through Divi's plain page.php inside a .container (width:80%, max-width:1080px), which
   is what motivated only breaking out the Redoc reference section rather than the whole page --
   prose read fine at that width, matching every other plain shortcode page (e.g. /status/, since
   fixed the same way). That specific ancestor is gone post-CR-10 (confirmed live, no more
   `.container` in the response), but the reasoning still holds at the new 1200px cap, and the
   breakout rule below doesn't actually depend on knowing the exact number either way -- it's
   viewport-relative. Redoc's three-pane layout (nav/content/code samples) is what actually needed
   the extra room. `:has()` scopes the breakout to this one page without a page-ID selector, which
   Divi doesn't guarantee stays put across a page re-create.

   overflow-x: clip on the page is load-bearing, same reasoning as .cs-page--browse .cs-filters:
   `vw` units include the scrollbar's width, so on a desktop with a classic scrollbar the section
   would overhang by half a scrollbar each side and mint a horizontal scrollbar of its own. */
body:has(.cs-developer-docs) {
	overflow-x: clip;
}

.cs-developer-docs__reference {
	margin-inline: calc(50% - 50vw);
	padding-inline: 4vw;
}

/* Redoc renders its own React tree with its own CSS-in-JS styling, not by inheriting this page's
   cascade (see developer-docs-init.js's docblock) -- most of its theme is bridged there at runtime
   from these same --cs-* tokens, except one real gap: Redoc 2.x has no theme option for the main
   content pane's own page background (confirmed against the vendored bundle's default theme
   object and Redocly's own theming docs). `.redoc-wrap`/`.api-content` are real, stable,
   non-hashed class names Redoc puts on that pane -- not styled-components' generated hashes --
   so this is a safe, specific hook rather than a guess at internal markup. */
#cs-redoc-container .redoc-wrap,
#cs-redoc-container .api-content {
	background: var(--cs-surface);
}

/* Same real gap, different control: the "Request samples" language tab (`.dropdown-select`, also a
   real Redoc class name, not a styled-components hash) isn't in the theme object either -- it's a
   plain-styled dropdown Redoc renders regardless of theme. */
#cs-redoc-container .dropdown-select {
	background: var(--cs-surface-sunken);
	color: var(--cs-text);
}

/* Not a missing theme option this time -- a theme option whose own hardcoded CSS assumes a light
   main pane / dark right panel split that no longer holds once both go dark. Redoc's selected-tab
   pill (`.react-tabs__tab--selected`, react-tabs' own stable class, confirmed against the vendored
   bundle's source) is styled `color: theme.colors.text.primary; background: theme.rightPanel.
   textColor` -- in Redoc's own default theme those are two unrelated colours (a dark grey, a white)
   that happen to contrast because one theme is light-mode and the other dark-mode. Point both at
   this project's tokens instead and they're both light-on-dark text colours, so the pill vanishes
   (verified with a computed-style probe: background and color resolved to the identical value).

   `:not(.tab-success, .tab-error, .tab-redirect, .tab-info)` matters: the SAME base rule and the
   SAME class also cover the Response samples status-code tabs (200/400/…), which are fine as-is --
   the http-status modifier classes override `color` to `colors.responses.*.main` (untouched,
   Redoc's own defaults) independently of `colors.text.primary`, so they never hit this collision.
   The only broken case is a plain selected tab with no status modifier (e.g. "Payload" when a spec
   has just one code sample language) -- overriding the pill directly with the same solid-fill/
   on-fill pairing this site's own buttons already use elsewhere sidesteps the swapped-variable
   assumption rather than fighting it, without touching the status tabs that already work. */
#cs-redoc-container .react-tabs__tab--selected:not(.tab-success, .tab-error, .tab-redirect, .tab-info) {
	background: var(--cs-brand-500);
	color: var(--cs-on-brand);
}

/* CR-18: three more confirmed gaps in the same theming pass, found via a live contrast scan
   (colors resolved via getComputedStyle against the actual rendered dark background, not read from
   source). All three are real, stable Redoc/react-tabs class names on the vendored bundle's own
   injected stylesheet -- not styled-components hashes -- so, same as `.redoc-wrap`/`.dropdown-select`
   above, safe hooks rather than a guess at internal markup. */

/* Every section label in the params/body panes (h5: "Authorizations:", "query Parameters", "path
   Parameters", "Request Body schema: ...") hardcodes `color: rgba(38, 50, 56, .5)` -- confirmed via
   the injected stylesheet -- a dark, low-opacity grey meant to sit on Redoc's default white page.
   No theme key covers it; `h5` is Redoc's own semantic tag for this role in the panel, not a guess. */
#cs-redoc-container h5 {
	color: var(--cs-text-muted);
}

/* The request-body media-type label ("application/json") hardcodes `color: black` in its own
   styled-components rule (class `.TDHxu`, confirmed via the injected stylesheet) -- no theme key
   covers this one either, unlike the label text around it. */
#cs-redoc-container .TDHxu {
	color: var(--cs-text);
}

/* The selected-tab pill fix above (`.react-tabs__tab--selected:not(...)`) deliberately left the
   http-status modifier classes alone because their `color` override (`colors.responses.*.main`)
   avoided the collision on its own -- but that reasoning assumed `colors.error.main` stayed a
   dark-on-light red. Now that developer-docs-init.js re-themes it to a light-on-dark
   `--cs-danger-text` (CR-18), a *selected* error tab would pair that light text with the shared
   `rightPanel.textColor` pill background (also light) and vanish the same way the plain pill did.
   Give the selected error tab its own dark tint/text pairing instead of the shared background. */
#cs-redoc-container .tab-error.react-tabs__tab--selected {
	background: var(--cs-danger-tint);
	color: var(--cs-danger-text);
}

/* Redoc's own three-pane layout needs room to breathe; below 480px it degrades to Redoc's default
   stacked/single-column behavior, which is acceptable but should be re-checked against this
   project's mobile-first bar (docs/06) once the panel is actually rendering real content — see
   docs/52 §1's "a11y / mobile-first pass" note. Nothing to override here until that check happens. */
@media (min-width: 480px) {
	#cs-redoc-container {
		min-height: 60vh;
	}
}

/* Found live 2026-08-26 while chasing the CR-25 Console-mirror clipping report
   (docs/visuals/cr25-console-redoc-2026-08-26): the request/response JSON code samples' own
   scroll box (Redoc's `.redoc-json`, wrapped by a styled-components div with no stable class name
   — hence targeting via :has() rather than guessing a hashed one) already has real
   `overflow-x: auto` and genuinely scrolls (confirmed: setting scrollLeft moves the content,
   verified with a before/after screenshot pair in that same docs/visuals folder) — the data was
   never actually lost, on EITHER /developers/ or the Console mirror (confirmed present on both:
   this is a pre-existing Redoc gap, not something CR-25 introduced). The real bug is that no
   scrollbar is visible at all, so nothing tells a visitor there's more to scroll to. A thin,
   on-brand scrollbar makes the existing scroll behavior discoverable rather than changing it. */
#cs-redoc-container div:has(> .redoc-json) {
	scrollbar-width: thin;
	scrollbar-color: var(--cs-border-strong) var(--cs-surface-sunken);
}

#cs-redoc-container div:has(> .redoc-json)::-webkit-scrollbar {
	height: 8px;
}

#cs-redoc-container div:has(> .redoc-json)::-webkit-scrollbar-track {
	background: var(--cs-surface-sunken);
}

#cs-redoc-container div:has(> .redoc-json)::-webkit-scrollbar-thumb {
	background: var(--cs-border-strong);
	border-radius: 4px;
}