Skip to content

docs: give widget reference screenshots a light surface in dark mode#4404

Open
mvanhorn wants to merge 1 commit into
beeware:mainfrom
mvanhorn:docs/widget-screenshots-dark-mode-4389
Open

docs: give widget reference screenshots a light surface in dark mode#4404
mvanhorn wants to merge 1 commit into
beeware:mainfrom
mvanhorn:docs/widget-screenshots-dark-mode-4389

Conversation

@mvanhorn
Copy link
Copy Markdown
Contributor

@mvanhorn mvanhorn commented May 18, 2026

Summary

Scopes a CSS rule to [data-md-color-scheme="slate"] so transparent widget reference PNGs get a light surface in mkdocs-material dark mode. Fixes legibility for the OptionContainer page and other widget reference images.

Closes #4389

What changed

  • docs/en/stylesheets/toga.css: scoped rule giving widget reference images a white surface only in slate (dark) mode.
  • changes/4389.doc.md: towncrier doc fragment.

Light mode is pixel-identical (rule is scheme-scoped). Source PNGs are untouched.

PR Checks

  • I will abide by the BeeWare Code of Conduct
  • I have read and have followed the CONTRIBUTING.md file
  • This PR was generated or assisted using an AI tool

Assisted-by: Claude Opus 4.7

Closes beeware#4389.

The widget reference images under docs/en/reference/images/ are
transparent PNGs captured against the platform's default light surface.
In dark mode (mkdocs-material's 'slate' color scheme) the transparency
lets the page background bleed through, which renders dark widget chrome
and pure white labels against a near-black page and makes the screenshot
hard to parse - the OptionContainer reference page in the issue is the
clearest example, but every widget reference under the API docs is
affected the same way.

Add a single CSS rule in toga.css that targets images under
/reference/images/ when the slate color scheme is active and wraps them
in a white surface with a small padding/radius so the captured chrome
stays separated from the page background. Light mode is unchanged
(the rule is scoped to [data-md-color-scheme='slate']) and the source
PNGs are untouched - no recapture needed.
Copy link
Copy Markdown
Member

@freakboy3742 freakboy3742 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution.

This PR has all the signs of being generated by an AI tool - the PR description is excessively verbose, and doesn't include the information that we have explicitly asked for in our PR template. It has also failed to follow the basics of our contribution guide (which is why it is failing CI).

If you address these issues, we're happy to review. You should also familiarise yourself with our contribution guide and AI usage policy.

@mvanhorn
Copy link
Copy Markdown
Contributor Author

Apologies for the verbose body and missing disclosure - I have trimmed the description and added the Assisted-by: trailer per the BeeWare AI policy.

On CI: the failing job is tests/widgets/test_webview.py::test_static_content on linux-x11-qt only, loading data:text/html;charset=UTF-8,... instead of https://example.com/ and failing 6/6 retries with that same error. PR #4406 has the same job failing on the same backend, which looks like an intermittent WebView/runner issue rather than something this docs-only PR (one scoped CSS rule + towncrier fragment) would touch. Happy to dig further if useful.

@phildini
Copy link
Copy Markdown
Member

Much closer! Those checkboxes that the AI either didn't include or auto-removed are needed for PRs on this project:

  • I will abide by the BeeWare Code of Conduct
  • I have read and have followed the CONTRIBUTING.md file
  • This PR was generated or assisted using an AI tool

@mvanhorn
Copy link
Copy Markdown
Contributor Author

Thanks - re-added the checklist. All three boxes apply (already had Assisted-by: Claude Opus 4.7 in the body for the AI disclosure).

Copy link
Copy Markdown
Member

@freakboy3742 freakboy3742 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a novel approach to fixing the problem; however, it's not clear to me how you've tested this, because the RTD preview rendering of the OptionContainer example highlighted in the original issue doesn't appear to be affected by the proposed CSS fix. How did you verify that the proposed fix worked as intended?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Widget screenshots for for macOS are transparent; dark mode is hard to parse

3 participants