refactor: migrate to design tokens and remove terminal.css#36
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Reviewer's GuideRefactors the design system to centralize tokens and shared components in global.css, removes the legacy terminal.css, and updates layouts, pages, and the navbar to consume the new design tokens and shared utility classes while simplifying some JS behavior around the mobile menu. Sequence diagram for updated mobile navbar menu behaviorsequenceDiagram
actor User
participant HamburgerButton
participant MobileOverlay
participant DocumentBody
User->>HamburgerButton: click
HamburgerButton->>HamburgerButton: setMenuState(true)
HamburgerButton->>MobileOverlay: classList.add(open)
HamburgerButton->>DocumentBody: classList.add(no-scroll)
MobileOverlay->>MobileOverlay: inert = false
User->>MobileOverlay: click link a
MobileOverlay->>MobileOverlay: classList.add(instant-close)
MobileOverlay->>HamburgerButton: setMenuState(false)
HamburgerButton->>MobileOverlay: classList.remove(open)
HamburgerButton->>DocumentBody: classList.remove(no-scroll)
MobileOverlay->>MobileOverlay: inert = true
MobileOverlay->>MobileOverlay: void offsetHeight %% force reflow
Flow diagram for the updated design token system in global.cssflowchart LR
A[root_color_primitives]
B[semantic_tokens
-- surfaces, text, borders,
brand, states]
C[component_tokens
-- nav_height, depth,
focus]
D[legacy_aliases
-- bg-color, brand-color,
font-color]
E[components/layout/Navbar.astro]
F[layouts/BaseLayout.astro]
G[pages_*_and_blog_layouts]
A --> B
B --> C
B --> D
C --> E
C --> F
B --> E
B --> G
D --> G
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
📝 WalkthroughWalkthroughThis PR centralizes a token-based global stylesheet, migrates components and navbar styles to design tokens, tightens mobile navbar accessibility/overlay behavior, and removes many page-local inline styles. ChangesDesign Token System & Component Migration
Estimated code review effort 🎯 4 (Complex) | ⏱️ ~75 minutes Possibly Related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- The new design tokens look well structured, but you still have a few hard-coded colors in components (e.g.
.prose prebackground/header, code editor dots) that bypass the semantic tokens—consider mapping those to the new--surface-*/--brand-*variables for consistency and easier theming later. - You've moved a lot of page- and component-specific CSS into global
@layer components(e.g..hero-section,.page-banner,.project-header); if you intend these to be shared primitives, it may be worth tightening their naming or scoping (e.g. with a prefix) to avoid collisions with future one-off styles. - The
color-mix()usage in navbar and feature card hover states is nice, but it may not be supported in all target browsers; if you need wider compatibility, consider adding a simple fallback background color before thecolor-mix()declarations.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The new design tokens look well structured, but you still have a few hard-coded colors in components (e.g. `.prose pre` background/header, code editor dots) that bypass the semantic tokens—consider mapping those to the new `--surface-*`/`--brand-*` variables for consistency and easier theming later.
- You've moved a lot of page- and component-specific CSS into global `@layer components` (e.g. `.hero-section`, `.page-banner`, `.project-header`); if you intend these to be shared primitives, it may be worth tightening their naming or scoping (e.g. with a prefix) to avoid collisions with future one-off styles.
- The `color-mix()` usage in navbar and feature card hover states is nice, but it may not be supported in all target browsers; if you need wider compatibility, consider adding a simple fallback background color before the `color-mix()` declarations.
## Individual Comments
### Comment 1
<location path="src/components/layout/Navbar.astro" line_range="206-207" />
<code_context>
const link = event.target instanceof Element ? event.target.closest('a') : null;
if (link) {
- // Instantly hide overlay to prevent transition jank during navigation
overlayElement.classList.add('instant-close');
-
- isMenuOpen = false;
- overlayElement.classList.remove('open');
- hamburgerButton.classList.remove('active');
- hamburgerButton.setAttribute('aria-expanded', 'false');
- overlayElement.setAttribute('aria-hidden', 'true');
- document.body.classList.remove('no-scroll');
- document.documentElement.classList.remove('no-scroll');
- overlayElement.inert = true;
-
- // Force a synchronous layout reflow.
- // This ensures the browser flushes its layout queue and applies the
- // 'instant-close' state immediately BEFORE Astro View Transitions
- // or the browser starts painting the next page, preventing animation jank.
+ setMenuState(false);
void overlayElement.offsetHeight;
}
</code_context>
<issue_to_address>
**issue (bug_risk):** The `instant-close` class is never cleared, so subsequent opens may lose the slide-in animation.
Because `setMenuState` only toggles the `open` class, `instant-close` remains on the overlay after navigation. On the next open, `.mobile-overlay.instant-close` still disables the transition (opacity/visibility are applied instantly), so the panel never animates. Please clear `instant-close` when reopening (e.g. in `setMenuState(true)`) or via a `transitionend`/`animationend` handler so only the first navigation short-circuits the animation.
</issue_to_address>
### Comment 2
<location path="src/components/ui/ProgressBar.astro" line_range="55" />
<code_context>
width: 100%;
height: 100dvh;
- background: #fdfdf8;
- z-index: 999999;
+ background: var(--surface-page);
+ z-index: var(--z-overlay);
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Progress bar z-index is hard-coded instead of using the new z-index token, and may conflict with the mobile overlay.
Since we now have both `--z-progress` and `--z-overlay`, this component should use the dedicated progress token instead of `var(--z-overlay)`. That will keep layering consistent and avoid the progress bar sharing a stacking level with the mobile overlay, which could lead to unexpected overlaps based on DOM order.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/components/layout/Navbar.astro (1)
160-162:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAvoid focusing a hidden hamburger when closing on desktop resize.
When
setMenuState(false)is triggered afterwindow.innerWidth > 900, focus is moved tohamburgerButtoneven though it is hidden by CSS. This can leave keyboard users without a visible focus target.Suggested fix
else { - hamburgerButton.focus(); + if (window.innerWidth <= 900) { + hamburgerButton.focus(); + } else { + const desktopActive = + navbarElement.querySelector<HTMLElement>('.nav-link.active') ?? + navbarElement.querySelector<HTMLElement>('.nav-link') ?? + navbarElement; + desktopActive.focus(); + } }Also applies to: 187-190, 527-531
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/layout/Navbar.astro` around lines 160 - 162, When calling setMenuState(false) in the resize/close logic, avoid calling hamburgerButton.focus() unconditionally when the button is hidden; instead check that the hamburgerButton is visible/interactive before focusing (e.g., test computed style/offsetParent/aria-hidden/visibility or that window.innerWidth <= 900) and only call hamburgerButton.focus() when it will be a visible focus target. Update the three locations referenced (the block around setMenuState(false) with hamburgerButton.focus() at lines near 160–162, 187–190, and 527–531) to perform this visibility check before focusing.src/styles/global.css (1)
1354-1364:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winHonor reduced-motion for the animation utilities.
These helpers still run infinite animations when the user has
prefers-reduced-motion: reduceenabled. Because they are global utilities, one missing override reintroduces motion anywhere they are used.🧩 Suggested safeguard
`@layer` utilities { .animate-wiggle { animation: wiggle 0.5s ease-in-out infinite; } .animate-float { animation: float 3s ease-in-out infinite; } .animate-shimmer { background: linear-gradient(90deg, transparent 0%, rgba(255, 255, 255, 0.4) 50%, transparent 100%); background-size: 200% auto; animation: shimmer 2s linear infinite; } + + `@media` (prefers-reduced-motion: reduce) { + .animate-wiggle, + .animate-float, + .animate-shimmer { + animation: none; + } + }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/styles/global.css` around lines 1354 - 1364, The animation utilities (.animate-wiggle, .animate-float, .animate-shimmer) currently ignore user motion preferences; add a prefers-reduced-motion: reduce media query that overrides those utilities to disable animations (e.g., set animation: none !important and remove background animation for .animate-shimmer) so any use of these classes respects reduced-motion; target the same selectors (.animate-wiggle, .animate-float, .animate-shimmer) inside the media block to ensure the global utilities are fully disabled when the user requests reduced motion.
🧹 Nitpick comments (4)
src/pages/hosxp/herbready.astro (1)
111-111: ⚡ Quick winUse semantic text token for migrated page styles.
Line 111 still uses a legacy-style token (
--font-color-light). For consistency with this PR’s semantic-token migration, switch it to a semantic text token (for example--text-secondaryor--text-muted).Suggested diff
- .desc-line { color: var(--font-color-light); } + .desc-line { color: var(--text-secondary); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/pages/hosxp/herbready.astro` at line 111, The CSS rule for .desc-line uses the legacy token --font-color-light; update it to use a semantic text token (e.g., --text-secondary or --text-muted) to match the PR’s semantic-token migration, i.e., replace the value for .desc-line { color: var(--font-color-light); } with color: var(--text-secondary) (or --text-muted) so the class .desc-line uses a semantic token instead of --font-color-light.src/components/ui/ProgressBar.astro (1)
55-55: ⚡ Quick winReplace hardcoded progress bar z-index with a token.
z-index: 999999bypasses the new layering token system and can create brittle stacking behavior. Prefer a design token (or component token) for this layer.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/ui/ProgressBar.astro` at line 55, Replace the hardcoded z-index in src/components/ui/ProgressBar.astro (the CSS rule using "z-index: 999999") with a layering design token (for example a CSS variable like --z-layer-progress or the component token name used across the codebase), update the component to reference that token instead of the literal number, and if the token does not exist add it to the global tokens/vars (or theme) with the appropriate numeric value; keep the token name consistent with existing layer naming (e.g., z-layer-*) so other components can share it.src/components/layout/Navbar.astro (1)
316-318: ⚡ Quick winTokenize remaining hardcoded active-state colors.
A few active-state colors are still literal values (
#2b1f00,rgba(...)). Replacing these with semantic tokens will keep navbar theming consistent with the new token system.Also applies to: 489-492, 520-523
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/layout/Navbar.astro` around lines 316 - 318, Replace the remaining hardcoded active-state colors in the Navbar component CSS (the rules showing color: `#2b1f00` and the rgba(...) active/background/border values) with semantic design tokens (CSS custom properties) so theming is consistent; update the CSS rules in Navbar.astro that set color, background and border-color to use tokens like --color-text-on-brand, --brand-active-bg, --brand-btn-border (or your existing token names) and ensure the same replacements are applied to the other occurrences called out (the other rule blocks at the noted locations); if the tokens don't exist, add appropriately named tokens to the theme/token definitions and use those names in the Navbar styles.src/styles/global.css (1)
424-425: ⚡ Quick winRoute the CTA hover color through the token layer.
Line 425 hardcodes the primary button hover color, so palette updates will not flow through the new token contract. This should live beside the other brand button tokens instead of bypassing them here.
🎨 Token-based cleanup
:root { --brand-red: var(--color-red-600); --brand-orange: var(--color-orange-400); --brand-btn-shadow: var(--color-orange-600); --brand-btn-border: var(--color-orange-500); + --brand-btn-hover: `#f0a83a`; } .cta-button:hover { - background-color: `#f0a83a`; + background-color: var(--brand-btn-hover); color: var(--text-heading); transform: translateY(-1px); box-shadow: var(--depth-shadow-hover); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/styles/global.css` around lines 424 - 425, The .cta-button:hover rule currently hardcodes the hover color; replace that literal with the token used for brand button hover states (e.g., use the existing brand/button token like --button-cta-hover or add a new token such as --brand-cta-hover alongside the other brand button tokens) and update .cta-button:hover to reference that CSS variable instead of `#f0a83a` so palette changes flow through the token layer; also move or consolidate the token declaration next to the other brand button tokens rather than keeping a hardcoded value in global.css.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/styles/global.css`:
- Around line 823-829: The .blog-left-sidebar uses top: calc(var(--nav-height) +
1.5rem) but its max-height is fixed to calc(100vh - 4rem), causing the sidebar
to be taller than the remaining viewport; update max-height so it mirrors the
top offset (for example use calc(100vh - (var(--nav-height) + 1.5rem)) or
otherwise subtract the same var(--nav-height) + 1.5rem expression) to keep the
sticky sidebar height in sync with its offset.
- Around line 1053-1054: Remove deprecated word-wrap and word-break usages:
replace any "word-wrap: break-word" and "word-break: break-word" with
"overflow-wrap: break-word" (update the .prose code rule and the earlier
wrapping rule). Replace the hardcoded hover color in .cta-button:hover with the
design token (e.g. use var(--color-cta-hover) or the project's CTA hover token
name) for consistency. Fix sidebar sizing by making top and max-height use the
same nav-height offset (e.g. keep top using var(--nav-height) +/- spacing and
compute max-height as calc(100vh - var(--nav-height) - [same spacing]) so the
sidebar always fits the viewport). For .animate-wiggle, .animate-float,
.animate-shimmer, wrap or add prefers-reduced-motion: reduce rules to
disable/stop animations when the user requests reduced motion.
---
Outside diff comments:
In `@src/components/layout/Navbar.astro`:
- Around line 160-162: When calling setMenuState(false) in the resize/close
logic, avoid calling hamburgerButton.focus() unconditionally when the button is
hidden; instead check that the hamburgerButton is visible/interactive before
focusing (e.g., test computed style/offsetParent/aria-hidden/visibility or that
window.innerWidth <= 900) and only call hamburgerButton.focus() when it will be
a visible focus target. Update the three locations referenced (the block around
setMenuState(false) with hamburgerButton.focus() at lines near 160–162, 187–190,
and 527–531) to perform this visibility check before focusing.
In `@src/styles/global.css`:
- Around line 1354-1364: The animation utilities (.animate-wiggle,
.animate-float, .animate-shimmer) currently ignore user motion preferences; add
a prefers-reduced-motion: reduce media query that overrides those utilities to
disable animations (e.g., set animation: none !important and remove background
animation for .animate-shimmer) so any use of these classes respects
reduced-motion; target the same selectors (.animate-wiggle, .animate-float,
.animate-shimmer) inside the media block to ensure the global utilities are
fully disabled when the user requests reduced motion.
---
Nitpick comments:
In `@src/components/layout/Navbar.astro`:
- Around line 316-318: Replace the remaining hardcoded active-state colors in
the Navbar component CSS (the rules showing color: `#2b1f00` and the rgba(...)
active/background/border values) with semantic design tokens (CSS custom
properties) so theming is consistent; update the CSS rules in Navbar.astro that
set color, background and border-color to use tokens like --color-text-on-brand,
--brand-active-bg, --brand-btn-border (or your existing token names) and ensure
the same replacements are applied to the other occurrences called out (the other
rule blocks at the noted locations); if the tokens don't exist, add
appropriately named tokens to the theme/token definitions and use those names in
the Navbar styles.
In `@src/components/ui/ProgressBar.astro`:
- Line 55: Replace the hardcoded z-index in src/components/ui/ProgressBar.astro
(the CSS rule using "z-index: 999999") with a layering design token (for example
a CSS variable like --z-layer-progress or the component token name used across
the codebase), update the component to reference that token instead of the
literal number, and if the token does not exist add it to the global tokens/vars
(or theme) with the appropriate numeric value; keep the token name consistent
with existing layer naming (e.g., z-layer-*) so other components can share it.
In `@src/pages/hosxp/herbready.astro`:
- Line 111: The CSS rule for .desc-line uses the legacy token
--font-color-light; update it to use a semantic text token (e.g.,
--text-secondary or --text-muted) to match the PR’s semantic-token migration,
i.e., replace the value for .desc-line { color: var(--font-color-light); } with
color: var(--text-secondary) (or --text-muted) so the class .desc-line uses a
semantic token instead of --font-color-light.
In `@src/styles/global.css`:
- Around line 424-425: The .cta-button:hover rule currently hardcodes the hover
color; replace that literal with the token used for brand button hover states
(e.g., use the existing brand/button token like --button-cta-hover or add a new
token such as --brand-cta-hover alongside the other brand button tokens) and
update .cta-button:hover to reference that CSS variable instead of `#f0a83a` so
palette changes flow through the token layer; also move or consolidate the token
declaration next to the other brand button tokens rather than keeping a
hardcoded value in global.css.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 35c0117b-3764-44d6-9e3e-6e35b47d0d41
📒 Files selected for processing (18)
src/components/layout/Navbar.astrosrc/components/ui/FeatureCard.astrosrc/components/ui/ProgressBar.astrosrc/layouts/BaseLayout.astrosrc/layouts/BlogPostLayout.astrosrc/pages/about.astrosrc/pages/blog/categories/[category].astrosrc/pages/blog/index.astrosrc/pages/blog/tags/[tag].astrosrc/pages/hosxp/herbready.astrosrc/pages/hosxp/index.astrosrc/pages/index.astrosrc/pages/invs.astrosrc/pages/tools/cupsabot.astrosrc/pages/tools/herbs-app.astrosrc/pages/tools/index.astrosrc/styles/global.csssrc/styles/terminal.css
💤 Files with no reviewable changes (4)
- src/styles/terminal.css
- src/layouts/BaseLayout.astro
- src/pages/tools/herbs-app.astro
- src/pages/tools/cupsabot.astro
…ex for progress bar
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/layout/Navbar.astro`:
- Line 143: The issue: overlayElement.classList.remove('instant-close') is
executed unconditionally before toggling the overlay's 'open' class in
setMenuState, which breaks the intended instant-close when a nav link triggers
setMenuState(false). Fix it by moving or guarding that removal so it only
happens when the overlay is being opened (or after the 'open' class is toggled
off); specifically, in the code that calls
overlayElement.classList.remove('instant-close') (and in the setMenuState/open
toggle logic), either move the remove call to after toggling the 'open' class or
wrap it with a condition like if (nextOpen) so that clicking a nav link (which
calls setMenuState(false)) preserves the 'instant-close' class until after the
instant-close behavior has taken effect.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6823442e-4a38-4825-878a-50aefb46f9ce
📒 Files selected for processing (3)
src/components/layout/Navbar.astrosrc/components/ui/ProgressBar.astrosrc/styles/global.css
There was a problem hiding this comment.
♻️ Duplicate comments (1)
src/styles/global.css (1)
1101-1110:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winRemove the deprecated
word-break: break-worddeclarations.Line 1109 and Line 1211 still use a deprecated CSS keyword that stylelint flags today. Keep
overflow-wrapfor the table headers and switch the inline-code rule tooverflow-wrapinstead so this stylesheet stays lint-clean.♻️ Minimal fix
.prose code { font-family: var(--font-mono); background-color: var(--surface-accent); color: var(--brand-red); border: 1px solid var(--border-default); padding: 0.15em 0.4em; border-radius: var(--radius-sm); font-size: 0.875em; - word-break: break-word; + overflow-wrap: anywhere; } @@ .prose th { background-color: var(--surface-accent); color: var(--text-primary); font-weight: 600; text-align: left; padding: var(--space-3) var(--space-4); border-bottom: 2px solid var(--border-default); overflow-wrap: break-word; - word-break: break-word; }Also applies to: 1203-1212
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/styles/global.css` around lines 1101 - 1110, The .prose code rule currently uses the deprecated word-break: break-word; update this selector (".prose code") to remove word-break and add overflow-wrap: anywhere; (or overflow-wrap: break-word) to preserve the same wrapping behavior; ensure you do not change the existing table header rules which already use overflow-wrap (the block around lines ~1203-1212) so the stylesheet remains stylelint-clean.
🧹 Nitpick comments (1)
src/components/layout/Navbar.astro (1)
304-309: ⚡ Quick winFinish the token migration for the active nav colors.
Line 305, Line 478, Line 509, and Line 510 still hardcode the active-state palette. Since this PR is moving the navbar to token-driven styling, these should come from semantic/component tokens too so future palette changes stay centralized.
🎨 Minimal token-based cleanup
.nav-link.active { - color: `#2b1f00`; + color: var(--text-heading); background: var(--brand-orange); border-color: var(--brand-btn-border); font-weight: 700; } @@ .mobile-link.active { - color: `#2b1f00`; + color: var(--text-heading); background: var(--brand-orange); border-color: var(--brand-btn-border); font-weight: 700; transform: none; } @@ .mobile-link.active .mobile-link-icon { - color: `#2b1f00`; - border-color: rgba(43, 31, 0, 0.2); + color: var(--text-heading); + border-color: color-mix(in srgb, var(--text-heading) 20%, transparent); background: rgba(255, 255, 255, 0.4); }Also applies to: 477-483, 508-512
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/layout/Navbar.astro` around lines 304 - 309, The CSS for the active nav state currently hardcodes colors in the .nav-link.active rule (and the duplicate rules around the other occurrences) — replace the literal values (color: `#2b1f00`; background: var(--brand-orange); border-color: var(--brand-btn-border); font-weight: 700) with semantic/component CSS tokens (for example use tokens like --nav-active-foreground, --nav-active-background, --nav-active-border and keep font-weight as a token or existing variable) so all occurrences of .nav-link.active and the duplicated blocks (the other navbar active-state rules) reference those tokens instead of hardcoded palette values.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@src/styles/global.css`:
- Around line 1101-1110: The .prose code rule currently uses the deprecated
word-break: break-word; update this selector (".prose code") to remove
word-break and add overflow-wrap: anywhere; (or overflow-wrap: break-word) to
preserve the same wrapping behavior; ensure you do not change the existing table
header rules which already use overflow-wrap (the block around lines ~1203-1212)
so the stylesheet remains stylelint-clean.
---
Nitpick comments:
In `@src/components/layout/Navbar.astro`:
- Around line 304-309: The CSS for the active nav state currently hardcodes
colors in the .nav-link.active rule (and the duplicate rules around the other
occurrences) — replace the literal values (color: `#2b1f00`; background:
var(--brand-orange); border-color: var(--brand-btn-border); font-weight: 700)
with semantic/component CSS tokens (for example use tokens like
--nav-active-foreground, --nav-active-background, --nav-active-border and keep
font-weight as a token or existing variable) so all occurrences of
.nav-link.active and the duplicated blocks (the other navbar active-state rules)
reference those tokens instead of hardcoded palette values.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: cbdc228f-ac4e-4804-ab9e-6fb301c9c43d
📒 Files selected for processing (3)
src/components/content/Table.astrosrc/components/layout/Navbar.astrosrc/styles/global.css
✅ Files skipped from review due to trivial changes (1)
- src/components/content/Table.astro
## [1.13.4](v1.13.3...v1.13.4) (2026-05-26) ### ♻️ Refactoring * migrate to design tokens and remove terminal.css ([#36](#36)) ([60e53ae](60e53ae))
|
🎉 This PR is included in version 1.13.4 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Summary by Sourcery
Consolidate the site’s styling into a single global design system, replacing page‑specific CSS with shared tokens, components, and utilities, and align navigation and layout behaviors with the new system.
Enhancements:
Chores:
Summary by CodeRabbit
New Features
Style
Bug Fixes