mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 01:45:10 +03:00
7f0d71cdb1
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Bug fix. ## What is the current behavior? In the docs site, **bold** text inside `.prose` content no longer renders as bold — it is indistinguishable from normal body text in light mode, and only a faint step heavier in dark mode. Root cause: the recent font work added a docs-only rule in `apps/docs/styles/globals.css`: ```css .prose :where(p, a, code, pre):not(...), .prose :where(ol > li):not(...)::marker { font-weight: inherit; } ``` This makes prose body text inherit the page base weight set on `html` (`font-weight: 500` in light, `450` in dark). But the shared typography config (`packages/config/typography.config.js`) defines `strong: { fontWeight: '500' }`. So: - **Light mode:** body copy is now `500` and `<strong>` is also `500` → bold is visually identical to normal text. - **Dark mode:** body copy is `450` vs `<strong>` `500` → barely perceptible. This is docs-specific: the other apps (`www`, etc.) never added the `font-weight: inherit` override, so their prose body stays at `400` and `strong: 500` still reads as bold. Changing the shared config would over-bolden those apps, so the fix is scoped to the docs stylesheet. ## What is the new behavior? Adds a docs-scoped override keeping bold text clearly heavier than the inherited body weight: ```css .prose :where(strong, b):not(:where([class~='not-prose'], [class~='not-prose'] *)) { font-weight: 600; } ``` `<strong>`/`<b>` now render at `600`, giving clear contrast against the `500`/`450` body weight in both light and dark modes, and matching the semibold weight used by prose headings. The other apps are untouched. ## Additional context - Single-file change in `apps/docs/styles/globals.css`. - Uses the same `:where(... :not(.not-prose) ...)` pattern as the surrounding prose rules to preserve `not-prose` opt-outs and keep zero-specificity behavior. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01RaT19RpEWwDFtzmVwmsPHo --- _Generated by [Claude Code](https://claude.ai/code/session_01RaT19RpEWwDFtzmVwmsPHo)_ <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved documentation typography so emphasized (bold) text is more clearly distinguishable from regular body copy. * Added a targeted prose styling override for `strong`/`b` to ensure consistent bold weight, while preserving sections that opt out of prose styling. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Miranda Limonczenko <miranda.limonczenko@supabase.io>
Reference Docs
Supabase Reference Docs
Maintainers
If you are a maintainer of any tools in the Supabase ecosystem, you can use this site to provide documentation for the tools & libraries that you maintain.
DocSpec
We use documentation specifications which can be used to generate human-readable docs.
- OpenAPI: for documenting API endpoints.
- SDKSpec (custom to Supabase): for SDKs and client libraries.
- ConfigSpec (custom to Supabase): for configuration options.
- CLISpec (custom to Supabase): for CLI commands and usage.
The benefit of using custom specifications is that we can generate many other types from a strict schema (eg, HTML and manpages). It also means that we can switch to any documentation system we want. On this site we use Next.js, but on Supabase's official website, we use a custom React site and expose only a subset of the available API for each tool.
Contributing
To contribute to docs, see the developers' guide and contributing guide.