Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📝 WalkthroughWalkthroughRemoved component-scoped <style> blocks from FrameworkSelector.astro and ConditionalQuestionnaire.astro and moved those styles into a new global stylesheet Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a59695bb0e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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 (1)
src/components/FrameworkSelector.astro (1)
63-104:⚠️ Potential issue | 🟡 MinorMissing
:focus-visiblestyle on.framework-button.There's no
:focusor:focus-visiblerule for the framework buttons. Keyboard users tabbing through the selector won't see a visible focus indicator beyond the browser default (which may be suppressed by the custom border/background). As per coding guidelines, all interactive elements must have visible focus states.Proposed fix (add to the style block or docs.css)
+ .framework-button:focus-visible { + outline: 2px solid var(--framework-border); + outline-offset: 2px; + }
🤖 Fix all issues with AI agents
In `@src/css/docs.css`:
- Around line 662-684: Add visible keyboard focus styles for the interactive
elements by implementing :focus-visible rules for .question-btn and
.react-framework-buttons .framework-button; specifically, update the CSS to
include a .question-btn:focus-visible selector (and .react-framework-buttons
.framework-button:focus-visible) that applies a clear outline or border-color
(e.g., var(--sl-color-blue)), maintains sufficient contrast (adjust background
or color if needed), and includes the same transition used for hover so keyboard
focus is visually consistent with hover/selected states.
- Around line 594-600: The global .sl-steps rules are too broad and interactive
elements lack visible keyboard focus; scope the rules to the questionnaire by
changing selectors to `#questionnaire-steps` .sl-steps (or move the block under
the `#questionnaire-steps` container) and add :focus-visible styles for the
interactive controls (selectors .question-btn and .framework-button) so keyboard
focus is visible (e.g., outline and outline-offset). Also remove or consolidate
the duplicate definitions so styling exists in one place (either
src/css/docs.css or the Astro component) to avoid drift.
🧹 Nitpick comments (3)
src/components/FrameworkSelector.astro (1)
51-220: Duplicate CSS: styles here and indocs.cssare both global and nearly identical.Since Line 51 now makes this
<style is:global>, these rules will coexist with the identical block indocs.css. This means any future style tweak must be synchronized in two places. Consider removing the styles from one location — either keep them only indocs.css(the stated production fix) and strip this block down to a comment/reference, or remove them fromdocs.css.src/css/docs.css (2)
786-802: Hardcoded diff colors may have poor contrast in light mode.The green (
#22c55e) and red (#ef4444) diff text colors are hardcoded. On a light background, these may not meet WCAG contrast requirements. Consider using CSS custom properties that adapt to the theme, or verify contrast ratios in light mode.
597-651: Stylelint violations: missing empty lines before declarations.The linter flagged Lines 597, 639, and 651 for
declaration-empty-line-before. These are minor formatting issues.Fix: add blank lines before the flagged declarations
.sl-steps { --bullet-size: calc(var(--sl-line-height) * 1rem); --bullet-margin: 0.375rem; + list-style: none;.sl-steps > ol > li::after { --guide-width: 1px; + content: '';.sl-steps > ol > li > :first-child { --lh: calc(1em * var(--sl-line-height)); --shift-y: calc(0.5 * (var(--bullet-size) - var(--lh))); + transform: translateY(var(--shift-y));
Before / After ScreenshotsBefore (Production — broken)Framework selector buttons render as full-size unstyled images: 
After (Dev server — fixed)Framework selector buttons render as compact styled cards in a grid: 
Also in this update: removed redundant |
…o interactive buttons - Scope all .sl-steps selectors under #questionnaire-steps to avoid overriding Starlight's native step component styles elsewhere - Add :focus-visible outlines to .framework-button, .question-btn, and .react-framework-buttons .framework-button for keyboard accessibility Addresses CodeRabbit review feedback on PR #472.
Change font-family from var(--sl-font) to inherit so buttons get the full Starlight font stack with fallbacks. Bump font-size from var(--sl-text-sm) to var(--sl-text-body) to match surrounding text.
var(--sl-font-mono) only resolves to 'IBM Plex Mono' without fallbacks. When that font isn't loaded, code blocks fall back to the browser's default proportional font. Add the same fallback stack Starlight uses for its own <code> elements.
|
2 participants
Problem
Framework selector buttons on docs pages (e.g.,
/docs/plugins/updater/notify-app-ready/) display as unstyled full-size images in production but look correct in dev mode.Root Cause
Astro drops
<style>blocks (both scoped andis:global) from components imported inside MDX content collection pages during static build. The HTML output has the scoped class attributes but zero CSS rules in the built CSS files.Solution
Moved all FrameworkSelector and ConditionalQuestionnaire styles to
src/css/docs.css, which is included via Starlight'scustomCssconfig and is guaranteed to be bundled in production builds.Files Changed
src/css/docs.css— Added styles for FrameworkSelector and ConditionalQuestionnaire componentssrc/components/FrameworkSelector.astro— Minor:<style>→<style is:global>(for clarity, though styles now live in docs.css)Before/After Screenshots
Production Before Fix (Broken)
Framework selector buttons appear as full-size unstyled images instead of compact button groups.
See:
prod-page.pngLocal Build Before Fix (Broken)
Same issue as production—styles are stripped during build.
See:
built-page.pngLocal Build After Fix (Correct)
Framework selector buttons display correctly with proper styling and layout.
See:
built-fixed.pngDev Server (Reference)
Dev server always worked correctly because Astro's dev mode preserves component styles.
See:
dev-page.pngTesting
npm run dev) — buttons render correctlynpm run build) — buttons render correctly after fixSummary by CodeRabbit
New Features
Style