docs: update logo to donut brand mark with pink accent - #1837
Conversation
Replace the monochrome hex-mesh logo with the new donut mark. The dough crescent uses currentColor in the inlined header logo (and a prefers-color-scheme swap in the favicon) so it follows light/dark mode; the pink frosting stays #ff6ca5. The theme accent moves from monochrome to the brand pink, darkened in light mode so white accent text keeps AA contrast, with dark-mode accent text flipped dark in theme.css.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
More templates
@orpc/ai-sdk
@orpc/arktype
@orpc/bun
@orpc/client
@orpc/cloudflare
@orpc/contract
@orpc/experimental-effect
@orpc/evlog
@orpc/hibernation
@orpc/json-schema
@orpc/nest
@orpc/next
@orpc/node
@orpc/openapi
@orpc/opentelemetry
@orpc/pinia-colada
@orpc/pino
@orpc/publisher
@orpc/ratelimit
@orpc/server
@orpc/shared
@orpc/swr
@orpc/tanstack-query
@orpc/trpc
@orpc/valibot
@orpc/zod
commit: |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Merging this PR will improve performance by 10.51%
Performance Changes
Tip Curious why this is faster? Comment Comparing 
|
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
logo.svg/icon.svg— replaced the monochrome hex-mesh mark with the donut brand mark; the dough crescent follows the theme (currentColorin the header logo,.mono+prefers-color-schemein the favicon) while the pink frosting stays fixed at#ff6ca5.blume.config.ts— accent switched to brand pink, darkened in light mode for AA contrast with white accent text.theme.css— keeps the dark-mode accent-foreground flip to dark, with clarified contrast justification.
Verified the load-bearing contrast claims: the light accent oklch(0.58 0.19 359) comes out to ~4.75:1 against white (your stated 4.7:1 ✓, passes AA normal text), the dark-mode accent text over the page background is ~5.3:1, and the dark accent-foreground against #ff6ca5 is ~7.9:1 (your stated 7.5:1 ✓). The header logo already used fill="currentColor" before this change, so switching the dough to track the theme's foreground is an established, working pattern rather than a new risk. Both color strategies are documented and consistent.
DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏
The near-black dough read harsh next to the pink frosting in light mode; it is now a warm gray (#585455) via an --orpc-logo-dough variable in theme.css (the inlined header logo picks it up, dark mode falls back to currentColor) and hard-coded in the favicon's light branch. Also ship public/favicon.ico (16/32/48 PNG entries, light colors) as a fallback at the conventional /favicon.ico path: Blume links only the SVG icon, and Google Search does not reliably render SVG favicons.
There was a problem hiding this comment.
Important
The new public/favicon.ico isn't a fallback — it replaces the adaptive SVG favicon. Blume resolves the site favicon to a single file, and public/favicon.ico outranks the root icon.svg, so the <link rel="icon"> now serves a static raster and the favicon's prefers-color-scheme dough swap is dropped for the site. In dark theme the fixed #585455 dough sits at ~2.2:1 against browser tab chrome — dimmer than the white dough it replaced.
Reviewed changes
- Softened the light-mode logo dough — the header logo and
icon.svgnow use#585455instead of near-black#1b1b1f, so the mark doesn't read harsh next to the pink frosting. - Themed the header logo dough through a CSS variable —
logo.svgnow usesfill: var(--orpc-logo-dough, currentColor), withtheme.csssetting#585455in light mode andcurrentColorin dark mode (so dark mode is unchanged). - Added
public/favicon.ico— a 16/32/48px donut mark (pink#ff6ca5frosting,#585455dough) intended as a favicon fallback.
Technical details
# favicon.ico displaces the adaptive SVG favicon
## Affected sites
- apps/content/public/favicon.ico (new) — becomes the primary favicon
- apps/content/icon.svg:3-6 — `.mono { fill: #585455 }` + dark-mode `#fff` swap no longer serves the site favicon (only the Scalar page at docs/openapi/scalar.mdx:78)
- blume/src/astro/generate.ts (`FAVICON_CANDIDATES` + `resolveFavicon`) — public-dir candidates win over project-root ones; `favicon.ico` at position 5 beats the root `icon.svg`
## Required outcome
- Reconcile intent vs effect: either keep the adaptive SVG favicon primary (move `icon.svg` into `apps/content/public/`, where `public/icon.svg` outranks `public/favicon.ico`; `/favicon.ico` direct requests still resolve to the raster as the fallback), or accept the static ico as the primary favicon and drop the now-misleading dark-mode swap claim in the PR body.
## Open questions for the human
- Was the dark-mode dough swap on the favicon intentional to keep, or acceptable to lose? The header still adapts; the ico doesn't.DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏
| <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 256 256"> | ||
| <style> | ||
| path { fill: #000; } | ||
| .mono { fill: #585455; } |
There was a problem hiding this comment.
public/favicon.ico isn't a fallback — it becomes the primary favicon. Blume resolves the site icon to a single candidate file and a public-dir favicon.ico outranks the root icon.svg, so the <link rel="icon"> now serves the static raster and the dark-mode dough swap below (@media (prefers-color-scheme: dark) { .mono { fill: #fff } }) no longer applies to the site favicon (icon.svg survives only in the Scalar page). In dark theme the fixed #585455 dough has ~2.2:1 contrast against browser tab chrome — far dimmer than the white dough it replaced.
If the intent is SVG-primary with the ico as a direct-request fallback, move icon.svg into apps/content/public/: public/icon.svg outranks public/favicon.ico in Blume's candidate order, so browsers get the adaptive SVG while /favicon.ico requests still serve the raster. Otherwise this is fine to ship as static — but the PR body's "favicon does the same via a prefers-color-scheme swap" claim would then be inaccurate.
Back to the near-black dough in light mode: logo.svg uses plain currentColor again (the --orpc-logo-dough variable is gone), the SVG favicon's light branch returns to #1b1b1f, and favicon.ico is regenerated to match. The ico fallback itself stays.
There was a problem hiding this comment.
ℹ️ This delta is clean — no new issues. The prior favicon-displacement concern (below) remains open, which is why this isn't an approval.
Reviewed changes (delta since the prior review)
- Reverted the light-mode dough softening —
logo.svgdough is back to plainfill="currentColor"and the--orpc-logo-doughvariable was removed fromtheme.csswith no dangling references left behind. - Reverted
icon.svg.monofill to near-black#1b1b1fin light mode.
The revert actually brings the code back in line with what the PR body already describes (dough = currentColor, near-black in light / light gray in dark), so it removes a doc-vs-code mismatch rather than introducing one. No correctness concerns in this delta.
One open item from the prior review is untouched by this commit and remains unresolved: public/favicon.ico still displaces the adaptive icon.svg as the site favicon, while the PR body still claims the favicon adapts via a prefers-color-scheme swap. The thread on that finding stays open.
DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏
Replaces the monochrome hex-mesh logo with the new donut brand mark and moves the docs site accent from monochrome to the logo's pink, tuned so everything stays legible in both light and dark mode.
Theming
currentColor(Blume inlines the SVG), so it renders near-black in light mode and light gray in dark mode; the favicon does the same via aprefers-color-schemeswap. The pink frosting stays#ff6ca5in both.oklch(0.58 0.19 359)) in light mode: raw#ff6ca5on white is 2.6:1, the darkened pink keeps white button text at 4.7:1 AA.theme.cssoverride flipping accent text dark — Blume forces white accent text there, which would fail contrast on the light pink (dark text is 7.5:1).Verification
Rendered the mark, primary button, and accent text on both themes with headless Chrome; all combinations legible, no full docs build run.