Rebrand: update primary colour to red and replace navbar/footer logo#265
Conversation
chris-absmartly
requested review from
bmsilva,
calthejuggler,
marcio-absmartly and
mario-silva
as code owners
WalkthroughThis pull request updates site branding: navbar and footer logo sources are changed to img/absmartly-icon.png and the navbar logo sizing style is adjusted. The SCSS imports the Manrope font and replaces Infima’s light- and dark-theme primary colour custom properties (and derived shades) with a new orange/warm palette, and adds a local PolySans face used for headings. No component logic or JS APIs are modified. Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 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 |
✅ Deploy Preview for absmartly-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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/scss/custom.scss`:
- Around line 11-17: The primary light-mode color (`#CA3721`) fails WCAG AA
contrast, so add an explicit override for the Infima contrast text variable by
defining --ifm-color-primary-contrast-foreground in custom.scss; set it to a
dark text color that yields at least 4.5:1 contrast against `#CA3721` (for
example, use a very dark value such as `#1b1b1b`) so that components using
--ifm-color-primary will render accessible foreground text in light mode.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 21e19492-8b8a-41fb-96b0-8ae5fd6d85ad
⛔ Files ignored due to path filters (1)
static/img/absmartly-icon.pngis excluded by!**/*.png
📒 Files selected for processing (2)
docusaurus.config.jssrc/scss/custom.scss
| --ifm-color-primary: #CA3721; | ||
| --ifm-color-primary-dark: #b6311e; | ||
| --ifm-color-primary-darker: #ac2e1c; | ||
| --ifm-color-primary-darkest: #8e2617; | ||
| --ifm-color-primary-light: #d4503c; | ||
| --ifm-color-primary-lighter: #d75c49; | ||
| --ifm-color-primary-lightest: #e18476; |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What are the WCAG contrast ratio requirements for interactive UI elements and how can I verify if colours #CA3721and#F4665C meet these requirements?
💡 Result:
WCAG contrast ratio requirements for interactive UI elements 1) Non-text contrast for interactive UI components (WCAG 2.x Success Criterion 1.4.11) - Requirement: Any visual information needed to identify an active user interface component (and its states) must have a contrast ratio of at least 3:1 against adjacent colors, unless the component is inactive or the appearance is determined by the user agent and not modified by the author. [1][2] - State indication: Visual information necessary to indicate state (e.g., selected or focused) must also meet the 3:1 contrast ratio against the adjacent colors for that state. [1][3] 2) Text contrast (in case your interactive element contains text) - WCAG 2.2 Success Criterion 1.4.3 (Contrast (Minimum)): Text and images of text must have contrast of at least 4.5:1 (with standard exceptions). [4][5] - WCAG 2.2 Success Criterion 1.4.6 (Contrast (Enhanced)): Text and images of text must have contrast of at least 7:1 (with standard exceptions). [4][5] (These are separate from the non-text 3:1 requirement for UI component shapes, outlines, icons, etc.) How to verify whether #CA3721 and #F4665C meet the interactive (non-text) 3:1 requirement Step A: Know what you’re measuring - For SC 1.4.11 you compare the “non-text visual cue” used to identify the control/state against the adjacent color(s). [1] - Typical cases: button background vs surrounding page/background, icon/border/outline vs its adjacent background, focus ring vs the area it touches. [1] Step B: Compute/confirm the contrast ratio between your two colors - WCAG defines contrast ratio using relative luminance. (Tools implement the calculation.) - Use a contrast checker that reports WCAG AA/AAA pass/fail and ratio, entering foreground/background as the two hex colors. For example, WebAIM’s Contrast Checker takes foreground and background hex values. [6] Step C: Interpret against the SC 1.4.11 threshold - If the relevant “non-text” part of your interactive UI has contrast ratio ≥ 3:1 against the adjacent color(s), it meets SC 1.4.11’s minimum non-text contrast requirement for active controls/states. [1][5] Important: #CA3721 vs #F4665C can only be judged in context - SC 1.4.11 requires 3:1 contrast against adjacent colors, not just between arbitrary brand colors. [1] - So you should measure “the state indicator” color against the actual adjacent rendered background color in each UI state (default, hover, focus, selected). [1] Practical checklist to verify in your UI 1) Identify each interactive element’s “informative non-text cue” (border/outline/fill, icon color, focus ring, etc.). [1] 2) For each state (including focus/selected/hover), sample the exact adjacent colors that touch that cue in the rendered UI. 3) Run those two hex pairs through a WCAG contrast checker and confirm the ratio is ≥ 3:1 (for SC 1.4.11). [6][1] 4) If your interactive element includes text, separately verify text contrast against its background using 4.5:1 (minimum) or 7:1 (enhanced) as applicable. [4][5] If you tell me what #CA3721 and #F4665C represent in your UI (e.g., border vs page background, button fill vs adjacent area, focus ring vs button background, icon vs background) and the states you care about, I can specify exactly which color pair(s) to test against each other for SC 1.4.11.
Citations:
- 1: https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast
- 2: https://www.w3.org/TR/WCAG22/
- 3: https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html
- 4: https://w3c.github.io/wcag/guidelines/22
- 5: https://w3.org/TR/2024/REC-WCAG22-20241212
- 6: https://webaim.org/resources/contrastchecker/
🏁 Script executed:
cat -n src/scss/custom.scss | head -50Repository: absmartly/docs
Length of output: 1911
🏁 Script executed:
# Search for references to these colour variables in the codebase
rg 'ifm-color-primary' --max-count 20 -A 2 -B 2Repository: absmartly/docs
Length of output: 1598
🏁 Script executed:
# Look for background or adjacent colours that would be used with these primary colours
rg 'ifm-color-background|background-color' src/scss/ --max-count 20Repository: absmartly/docs
Length of output: 210
🏁 Script executed:
# Search for Infima imports or documentation
find . -name "*.md" -o -name "*.json" | xargs grep -l "infima\|docusaurus" | head -10Repository: absmartly/docs
Length of output: 143
🏁 Script executed:
# Look for text colour definitions or button text colours
rg 'color:.*white|color:.*black|ifm-color-content|text-color' src/scss/ -A 1 -B 1Repository: absmartly/docs
Length of output: 40
🏁 Script executed:
# Check docusaurus config for theme colours
find . -name "docusaurus.config.*" -o -name "*.json" | head -5Repository: absmartly/docs
Length of output: 295
🏁 Script executed:
find . -name "docusaurus.config.js" -o -name "docusaurus.config.ts" | xargs catRepository: absmartly/docs
Length of output: 6318
🏁 Script executed:
cat package.json | grep -A 5 -B 5 "infima\|docusaurus"Repository: absmartly/docs
Length of output: 1370
🌐 Web query:
Infima CSS framework default button text colour and styling what colour does Infima use for button text
💡 Result:
Infima’s default button text styling uses the CSS variable --ifm-button-color (the “text color used for buttons”) which corresponds to the theme “button text” color, i.e. the variable --ifm-color--contrast- value depending on the button variant (e.g., primary uses the primary-contrast color). Docusaurus/Infima documents that --ifm-button-color is the text color for buttons and can be overridden via CSS variables. [1] Practically, unless you override variables, a regular (primary) Infima button will render its label using the relevant contrast text color token (e.g., “primary contrast” text color) because Infima defines buttons using color/contrast design tokens rather than a single fixed hex value. [1] If you’re trying to locate it in your generated CSS, search for “--ifm-button-color” usage in the compiled Infima/Docusaurus CSS; that variable is what controls the default button label color. [1]
Citations:
🌐 Web query:
Infima --ifm-color-primary-contrast default value white text buttons
💡 Result:
In Infima, the button text color for the “primary” color uses the contrast-foreground variable: --ifm-color-primary-contrast-foreground (not hardcoded to white). Docusaurus/Infima documents this variable naming and that it is a contrasting foreground color derived from the primary color for light/dark theming. [1] Default value for “primary contrast foreground” is theme-dependent (i.e., depends on what --ifm-color-primary is set to), so there is no single universal default value like “white”. In one documented Infima/Docusaurus preset variable set (preset-classic), the defaults are: - --ifm-color-primary: #3578e5 - --ifm-color-primary-contrast-foreground: #102445 [2][3] So, if your buttons look like white text “by default”, that’s either because your current theme’s generated --ifm-color-primary-contrast-foreground happens to be very light (or you’ve overridden the variable). To make them white explicitly, you can override the CSS variable in your app::root { --ifm-color-primary-contrast-foreground: #ffffff; } (Otherwise, Infima is designed to pick a contrasting foreground value automatically via the -contrast-foreground token.) [1]
Citations:
- 1: https://docusaurus.community/knowledge/design/css/variables/
- 2: https://gist.github.com/abhigyantrips/b828ca46b2460c6699c73e0162f6be80?permalink_comment_id=4838702
- 3: https://gist.github.com/abhigyantrips/b828ca46b2460c6699c73e0162f6be80
🏁 Script executed:
cat src/scss/custom.scss | grep -i "contrast"Repository: absmartly/docs
Length of output: 40
🌐 Web query:
Infima how does it calculate automatically primary-contrast-foreground colour algorithm
💡 Result:
Infima does not calculate its contrast foreground and background colors using a real-time, dynamic algorithm in the browser [1][2]. Instead, these values are generated statically during the build process using a color generator tool [1][2]. The generation process relies on predefined SCSS functions—specifically shade and tint—to create variations of a base color [2]. According to Infima's documentation and community knowledge, the calculation logic is as follows: 1. Contrast Foreground: The --ifm-color-{color}-contrast-foreground variable is generated by applying a shade function to the base color, making it 70% darker in light mode and 90% darker in dark mode [2]. 2. Contrast Background: The --ifm-color-{color}-contrast-background variable is generated by applying a tint function to the base color, making it 90% lighter in light mode and 70% lighter in dark mode [2]. Because these values are pre-computed and baked into the CSS variables at build time, they do not automatically adjust based on the specific luminance of the base color to guarantee WCAG contrast compliance [1][2]. This has been a known point of discussion in the Infima community, as users have noted that these generated defaults may not always meet accessibility standards for all color inputs [3]. Developers are encouraged to manually override these CSS variables in their project's custom CSS if the generated defaults do not provide sufficient contrast [4][2][3].
Citations:
- 1: Variables shouldn't use color-mod outside of initial palette generation facebookincubator/infima#163
- 2: https://docusaurus.community/knowledge/design/css/variables/
- 3: Theme colors do not meet accessibility standards for color contrast facebookincubator/infima#139
- 4: Document Infima variables facebook/docusaurus#3955
🏁 Script executed:
python3 << 'EOF'
from colorsys import rgb_to_hsv, hsv_to_rgb
def hex_to_rgb(hex_color):
hex_color = hex_color.lstrip('#')
return tuple(int(hex_color[i:i+2], 16) for i in (0, 2, 4))
def rgb_to_hex(rgb):
return '#{:02x}{:02x}{:02x}'.format(int(rgb[0]), int(rgb[1]), int(rgb[2]))
def shade(hex_color, percent):
"""Make a colour darker by percent (0-100)"""
r, g, b = hex_to_rgb(hex_color)
r, g, b = r / 255, g / 255, b / 255
h, s, v = rgb_to_hsv(r, g, b)
v = v * (1 - percent / 100) # reduce brightness
r, g, b = hsv_to_rgb(h, s, v)
return rgb_to_hex((r * 255, g * 255, b * 255))
# Light mode: `#CA3721` with 70% shade
light_primary = '`#CA3721`'
light_text = shade(light_primary, 70)
print(f"Light mode primary: {light_primary}")
print(f"Light mode contrast text (shade 70%): {light_text}")
# Dark mode: `#F4665C` with 90% shade
dark_primary = '`#F4665C`'
dark_text = shade(dark_primary, 90)
print(f"Dark mode primary: {dark_primary}")
print(f"Dark mode contrast text (shade 90%): {dark_text}")
EOFRepository: absmartly/docs
Length of output: 204
🏁 Script executed:
python3 << 'EOF'
def hex_to_rgb(hex_color):
hex_color = hex_color.lstrip('#')
return tuple(int(hex_color[i:i+2], 16) for i in (0, 2, 4))
def get_luminance(rgb):
"""Calculate relative luminance per WCAG"""
r, g, b = [x / 255.0 for x in rgb]
r = r / 12.92 if r <= 0.03928 else pow((r + 0.055) / 1.055, 2.4)
g = g / 12.92 if g <= 0.03928 else pow((g + 0.055) / 1.055, 2.4)
b = b / 12.92 if b <= 0.03928 else pow((b + 0.055) / 1.055, 2.4)
return 0.2126 * r + 0.7152 * g + 0.0722 * b
def contrast_ratio(color1_hex, color2_hex):
"""Calculate WCAG contrast ratio between two colours"""
rgb1 = hex_to_rgb(color1_hex)
rgb2 = hex_to_rgb(color2_hex)
l1 = get_luminance(rgb1)
l2 = get_luminance(rgb2)
lighter = max(l1, l2)
darker = min(l1, l2)
return (lighter + 0.05) / (darker + 0.05)
# Test cases
test_cases = [
("`#CA3721`", "`#1a0a04`"), # Light mode primary + estimated shade 70%
("`#F4665C`", "`#0a0201`"), # Dark mode primary + estimated shade 90%
]
for fg, bg in test_cases:
ratio = contrast_ratio(fg, bg)
passes_aa = "✓ WCAG AA" if ratio >= 4.5 else "✗ WCAG AA"
passes_aaa = "✓ WCAG AAA" if ratio >= 7 else "✗ WCAG AAA"
print(f"Contrast between {fg} and {bg}: {ratio:.2f}:1 {passes_aa} {passes_aaa}")
EOFRepository: absmartly/docs
Length of output: 194
Define --ifm-color-primary-contrast-foreground to ensure WCAG AA text contrast compliance in light mode.
The light mode primary colour (#CA3721) uses Infima's automatically calculated contrast text colour, which produces a contrast ratio of only 3.75:1—below the WCAG AA minimum of 4.5:1 for normal text. The dark mode colour (#F4665C) meets accessibility standards at 6.75:1, but the light mode requires an override. Add an explicit text colour variable to custom.scss to guarantee sufficient contrast.
🤖 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/scss/custom.scss` around lines 11 - 17, The primary light-mode color
(`#CA3721`) fails WCAG AA contrast, so add an explicit override for the Infima
contrast text variable by defining --ifm-color-primary-contrast-foreground in
custom.scss; set it to a dark text color that yields at least 4.5:1 contrast
against `#CA3721` (for example, use a very dark value such as `#1b1b1b`) so that
components using --ifm-color-primary will render accessible foreground text in
light mode.
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/scss/custom.scss`:
- Line 7: The SCSS import in src/scss/custom.scss uses url(...) which breaks
stylelint; replace the url(...) form with a plain string import (update the
`@import` line referencing the Google Fonts URL for the Manrope family) so
stylelint accepts the import and CI linting passes.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 85f189a9-57d4-4c3f-9a18-64c89067a68d
📒 Files selected for processing (2)
docusaurus.config.jssrc/scss/custom.scss
✅ Files skipped from review due to trivial changes (1)
- docusaurus.config.js
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
src/scss/custom.scss (2)
7-7:⚠️ Potential issue | 🟠 Major | ⚡ Quick winStylelint import notation is still in the failing form.
This is the same issue previously flagged, and the current line still uses
url(...), which violates the configuredimport-notationrule and can block CI.Proposed minimal fix
-@import url('https://fonts.googleapis.com/css2?family=Manrope:wght@200..800&display=swap'); +@import 'https://fonts.googleapis.com/css2?family=Manrope:wght@200..800&display=swap';🤖 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/scss/custom.scss` at line 7, The import line using url(...) violates the stylelint import-notation rule and must be changed to the string form; locate the `@import` line that currently contains "https://fonts.googleapis.com/css2?family=Manrope:wght@200..800&display=swap" and replace the url(...) usage with a plain string import (i.e., use the quoted URL directly) so the rule is satisfied and CI no longer fails.
24-43:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd explicit primary contrast foreground tokens for accessibility and consistency with Infima patterns.
The full primary colour scale is defined, but Infima recommends explicitly setting
--ifm-color-primary-contrast-foregroundtokens to ensure buttons and links maintain WCAG AA contrast. The suggested values (#fffffffor light mode,#1b1b1bfor dark mode) meet AA standards against the primary colours. Add these tokens to your:rootand[data-theme="dark"]blocks.Suggested addition
:root { @@ --ifm-color-primary-lightest: `#e18476`; + --ifm-color-primary-contrast-foreground: `#ffffff`; } @@ [data-theme="dark"] { @@ --ifm-color-primary-lightest: `#fbbbb6`; + --ifm-color-primary-contrast-foreground: `#1b1b1b`; }🤖 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/scss/custom.scss` around lines 24 - 43, Add explicit contrast-foreground CSS variables for the primary color in both light and dark scopes: define --ifm-color-primary-contrast-foreground: `#ffffff` in the :root block alongside the existing --ifm-color-primary tokens, and define --ifm-color-primary-contrast-foreground: `#1b1b1b` in the [data-theme="dark"] block; update the same-named token (and optionally the -hover/-active contrast tokens if present) so Infima components like buttons and links use these variables to meet WCAG AA contrast.
🤖 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/scss/custom.scss`:
- Line 10: Remove the unnecessary quotes around the font name in the font-family
declaration (change font-family: 'PolySans'; to font-family: PolySans;),
updating the declaration in src/scss/custom.scss where the font-family is set
(look for the font-family line referencing 'PolySans') so it conforms to the
font-family-name-quotes rule in stylelint-config-standard-scss.
---
Duplicate comments:
In `@src/scss/custom.scss`:
- Line 7: The import line using url(...) violates the stylelint import-notation
rule and must be changed to the string form; locate the `@import` line that
currently contains
"https://fonts.googleapis.com/css2?family=Manrope:wght@200..800&display=swap"
and replace the url(...) usage with a plain string import (i.e., use the quoted
URL directly) so the rule is satisfied and CI no longer fails.
- Around line 24-43: Add explicit contrast-foreground CSS variables for the
primary color in both light and dark scopes: define
--ifm-color-primary-contrast-foreground: `#ffffff` in the :root block alongside
the existing --ifm-color-primary tokens, and define
--ifm-color-primary-contrast-foreground: `#1b1b1b` in the [data-theme="dark"]
block; update the same-named token (and optionally the -hover/-active contrast
tokens if present) so Infima components like buttons and links use these
variables to meet WCAG AA contrast.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 21b0bb07-c250-412e-b427-b10bdbc47318
⛔ Files ignored due to path filters (3)
static/fonts/PolySans-Bulky.woffis excluded by!**/*.woffstatic/fonts/PolySans-Bulky.woff2is excluded by!**/*.woff2static/img/favicon.icois excluded by!**/*.ico
📒 Files selected for processing (1)
src/scss/custom.scss
| @import url('https://fonts.googleapis.com/css2?family=Manrope:wght@200..800&display=swap'); | ||
|
|
||
| @font-face { | ||
| font-family: 'PolySans'; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's read the SCSS file to see the current state
cat -n src/scss/custom.scss | head -60Repository: absmartly/docs
Length of output: 2359
🏁 Script executed:
# Search for Stylelint configuration files
fd -e json -e js -e yml -e yaml | grep -i stylelintRepository: absmartly/docs
Length of output: 40
🌐 Web query:
font-family-name-quotes Stylelint rule requirements
💡 Result:
Stylelint rule font-family-name-quotes: required/allowed quote behavior (rule options) Rule checks font and font-family properties and enforces whether font-family names are wrapped in quotes. It specifically ignores variable syntaxes like $sass, @less, and var(--custom-property) [1]. The rule’s configuration (primary option) is one of these values [1][2]: 1) "always" - Expects quotes around every font family name (including those that would otherwise be valid without quotes). [1] 2) "always-where-required" - Expects quotes only when they are required per the rule’s internal criteria; disallows quotes otherwise. [1] 3) "always-where-recommended" - Expects quotes only when they are recommended per the rule’s internal criteria; disallows quotes in all other cases. The documentation notes that quotes are recommended in CSS specs for font family names containing whitespace, digits, or punctuation (other than hyphens). [1] Important criteria described by the rule documentation - Generic font-family keywords (e.g., serif, sans-serif, monospace, etc.) should not be quoted by this rule, because quoting them makes the browser treat them as font names rather than generic fallbacks. The rule therefore enforces no quotes around these keywords (unless you disable or change the rule, and if you really want a font actually named "sans-serif", you should turn this rule off). [1] - Quotes are required for font-family names when they are not valid CSS identifiers. The Stylelint docs give examples: a font family name requires quotes if it contains $, !, or /, but it does not require quotes merely because it contains spaces or a (non-initial) number or underscore. [1] Autofix availability - As of the Stylelint issue discussion, the font-family-name-quotes rule does not currently have an autofix option (at least at the time of the report/response). [3] Example configuration - To require quotes only when they’re recommended by the criteria above: {"rules": {"font-family-name-quotes": "always-where-recommended"}} [3] If you tell me which option you’re using (e.g. always-where-recommended vs always-where-required vs always), I can restate the exact “quotes expected” behavior for the specific font-family patterns you care about.
Citations:
- 1: https://stylelint.io/user-guide/rules/font-family-name-quotes
- 2: https://github.com/stylelint/stylelint/blob/main/lib/rules/font-family-name-quotes/index.mjs
- 3: Support autofix for
font-family-name-quotesrule stylelint/stylelint#5805
🏁 Script executed:
# Search for Stylelint configuration in common locations
find . -maxdepth 2 -type f \( -name ".stylelintrc*" -o -name "stylelint.config.*" \) 2>/dev/nullRepository: absmartly/docs
Length of output: 78
🏁 Script executed:
# Check if Stylelint config is in package.json
cat package.json | grep -A 20 "stylelint"Repository: absmartly/docs
Length of output: 40
🏁 Script executed:
# Read the Stylelint configuration file
cat .stylelintrc.jsonRepository: absmartly/docs
Length of output: 1418
🌐 Web query:
stylelint-config-standard-scss font-family-name-quotes default configuration
💡 Result:
The stylelint-config-standard-scss package extends stylelint-config-standard [1][2]. The font-family-name-quotes rule is a core Stylelint rule [3][4], and its configuration is inherited from the standard Stylelint configuration [5]. In the standard Stylelint configuration, the font-family-name-quotes rule is typically set to "always-where-recommended" [6]. This option requires quotes around font family names only when they are recommended by the CSS specification (e.g., when the name contains spaces, numbers, or special characters) and disallows them in other cases [6]. To verify or override this setting in your project, you can explicitly define the rule in your Stylelint configuration file (e.g.,.stylelintrc.json or stylelint.config.mjs): { "extends": "stylelint-config-standard-scss", "rules": { "font-family-name-quotes": "always-where-recommended" } } You can change "always-where-recommended" to other available options such as "always-unless-keyword" or "always-where-required" depending on your project's specific requirements [6][7].
Citations:
- 1: https://github.com/stylelint-scss/stylelint-config-standard-scss
- 2: https://www.npmjs.com/package/stylelint-config-standard-scss
- 3: https://stylelint.io/user-guide/rules
- 4: https://stylelint.io/user-guide/rules/
- 5: https://github.com/stylelint/stylelint-config-standard
- 6: https://stylelint.io/user-guide/rules/font-family-name-quotes
- 7: "font-family-name-quotes" rule – "always-where-recommended" preferable wikimedia/stylelint-config-wikimedia#33
Remove quotes from PolySans to satisfy font-family-name-quotes rule.
The project uses stylelint-config-standard-scss, which configures font-family-name-quotes to always-where-recommended. This rule disallows quotes around font family names that are valid CSS identifiers. Since PolySans contains no spaces, special characters, or problematic punctuation, quotes are unnecessary and violate the rule.
Proposed minimal fix
`@font-face` {
- font-family: 'PolySans';
+ font-family: PolySans;
src: url('/fonts/PolySans-Bulky.woff2') format('woff2'),
url('/fonts/PolySans-Bulky.woff') format('woff');
@@
h1,
h2,
h3 {
- font-family: 'PolySans', var(--ifm-heading-font-family);
+ font-family: PolySans, var(--ifm-heading-font-family);
font-weight: 900;
}🧰 Tools
🪛 Stylelint (17.11.1)
[error] 10-10: Expected no quotes around "PolySans" (font-family-name-quotes)
(font-family-name-quotes)
🤖 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/scss/custom.scss` at line 10, Remove the unnecessary quotes around the
font name in the font-family declaration (change font-family: 'PolySans'; to
font-family: PolySans;), updating the declaration in src/scss/custom.scss where
the font-family is set (look for the font-family line referencing 'PolySans') so
it conforms to the font-family-name-quotes rule in
stylelint-config-standard-scss.
1 participant
Summary by CodeRabbit