fix(docs): Fix light mode text visibility in custom CSS

[Sridhar1030]

Summary

• Fixed light mode text being invisible (low contrast) when switching to Light in the Furo theme switcher
• Custom CSS was using :root:not([data-theme="light"]) for dark overrides, but Furo sets data-theme on body, not :root — so dark variable overrides always applied even in Light mode
• Switched theme checks to body-based selectors and added explicit body[data-theme="light"] block for correct light-mode colors
  Before

Fixes #331

After

Test plan

• Run make docs or make docs-serve
• Open docs in browser with OS/browser set to dark mode
• Click the Furo theme switcher and select Light — verify all text (sidebar, headings, body, TOC) is readable (dark on white)
• Switch to Dark — verify dark theme still works correctly

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign kramaranya for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Copilot]

Pull request overview

This PR fixes a light mode text visibility bug in the documentation where text appeared almost invisible (light grey on white background) when users switched to Light mode using the Furo theme switcher. The root cause was that the custom CSS was checking for data-theme on :root when Furo actually sets it on the body element, causing dark mode color variables to always apply.

Changes:

• Updated CSS selectors from :root-based to body-based to correctly detect Furo theme
• Added explicit body[data-theme="light"] block to ensure proper light mode colors when user selects Light theme
• Updated comment to clarify that Furo sets data-theme on body, not :root

Comments suppressed due to low confidence (1)

docs/source/_static/custom.css:73

• The --kf-accent variable is missing from this dark mode block (it's defined in :root at line 21). For consistency and maintainability, all CSS custom properties should be explicitly defined in each theme block. The dark mode might benefit from a different accent color, or it should explicitly set the same value for clarity.

body[data-theme="dark"] {
    --kf-blue: #63b3ed;
    --kf-blue-light: #90cdf4;
    --kf-blue-dark: #4299e1;
    --kf-heading: #e2e8f0;
    --kf-text: #cbd5e0;
    --kf-text-light: #a0aec0;
    --kf-bg-subtle: #2d3748;
    --kf-border: #4a5568;
    --kf-api-name: #63b3ed;
    --kf-api-param: #a0aec0;
    --kf-api-text: #e2e8f0;
}

[Copilot]

The --kf-accent variable is missing from this media query dark mode block (it's defined in :root at line 21). For consistency and maintainability, all CSS custom properties should be explicitly defined in each theme block.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

The body[data-theme="light"] block duplicates the exact same variable values already defined in :root, which increases the chance the light palette drifts out of sync over time; consider removing this block or limiting it to only the variables that truly need to differ from the :root defaults.

Suggested change

	/* Explicit light mode - ensure light vars when user selects Light */
	body[data-theme="light"] {
	--kf-blue: #4299e1;
	--kf-blue-light: #63b3ed;
	--kf-blue-dark: #3182ce;
	--kf-heading: #2d3748;
	--kf-text: #4a5568;
	--kf-text-light: #718096;
	--kf-bg-subtle: #f7fafc;
	--kf-border: #e2e8f0;
	--kf-accent: #81e6d9;
	--kf-api-name: #3182ce;
	--kf-api-param: #4a5568;
	--kf-api-text: #000;
	}

[Copilot]

The dark palette variables are defined twice (once in the @media (prefers-color-scheme: dark) block and again in body[data-theme="dark"]), which creates a maintenance hazard if one set of values is updated without the other; consider factoring the shared dark values so there is a single source of truth (e.g., alias variables or a shared selector strategy).

[andreyvelich]

/assign @kramaranya