Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions docusaurus.config.js
Original file line number Diff line number Diff line change
Expand Up @@ -134,9 +134,10 @@ const config = {
title: "ABsmartly Docs",
logo: {
alt: "The ABsmartly logo",
src: "img/logo.svg",
src: "img/absmartly-icon.png",
style: {
width: "3rem",
height: "2rem",
width: "auto",
},
},
items: [
Expand Down Expand Up @@ -211,7 +212,7 @@ const config = {
],
copyright: `© Copyright ${new Date().getFullYear()} ABsmartly B.V.`,
logo: {
src: "img/logo.svg",
src: "img/absmartly-icon.png",
alt: "The ABsmartly Logo",
style: { width: "3rem" },
},
Expand Down
48 changes: 34 additions & 14 deletions src/scss/custom.scss
Original file line number Diff line number Diff line change
Expand Up @@ -4,29 +4,49 @@
* work well for content-centric websites.
*/

@import url('https://fonts.googleapis.com/css2?family=Manrope:wght@200..800&display=swap');
Comment thread
coderabbitai[bot] marked this conversation as resolved.

@font-face {
font-family: 'PolySans';
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

# First, let's read the SCSS file to see the current state
cat -n src/scss/custom.scss | head -60

Repository: absmartly/docs

Length of output: 2359


🏁 Script executed:

# Search for Stylelint configuration files
fd -e json -e js -e yml -e yaml | grep -i stylelint

Repository: 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:


🏁 Script executed:

# Search for Stylelint configuration in common locations
find . -maxdepth 2 -type f \( -name ".stylelintrc*" -o -name "stylelint.config.*" \) 2>/dev/null

Repository: 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.json

Repository: 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:


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.

src: url('/fonts/PolySans-Bulky.woff2') format('woff2'),
url('/fonts/PolySans-Bulky.woff') format('woff');
font-weight: 900;
font-style: normal;
font-display: swap;
}

/* You can override the default Infima variables here. */
:root {
--ifm-font-family-base: 'Manrope', system-ui, -apple-system, sans-serif;
--ifm-heading-font-family: 'Manrope', system-ui, -apple-system, sans-serif;
--ifm-code-font-size: 95%;
--docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1);
--ifm-color-primary: #4a5af6;
--ifm-color-primary-dark: #2c3ef4;
--ifm-color-primary-darker: #1c30f4;
--ifm-color-primary-darkest: #0b1dd5;
--ifm-color-primary-light: #6876f8;
--ifm-color-primary-lighter: #7884f8;
--ifm-color-primary-lightest: #a5adfb;
--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;
Comment on lines +24 to +30
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 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:


🏁 Script executed:

cat -n src/scss/custom.scss | head -50

Repository: 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 2

Repository: 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 20

Repository: 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 -10

Repository: 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 1

Repository: absmartly/docs

Length of output: 40


🏁 Script executed:

# Check docusaurus config for theme colours
find . -name "docusaurus.config.*" -o -name "*.json" | head -5

Repository: absmartly/docs

Length of output: 295


🏁 Script executed:

find . -name "docusaurus.config.js" -o -name "docusaurus.config.ts" | xargs cat

Repository: 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:


🏁 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:


🏁 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}")
EOF

Repository: 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}")
EOF

Repository: 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.

}

/* For readability concerns, you should choose a lighter palette in dark mode. */
[data-theme="dark"] {
--docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3);
--ifm-color-primary: #8a95fa;
--ifm-color-primary-dark: #6573f8;
--ifm-color-primary-darker: #5262f8;
--ifm-color-primary-darkest: #1a30f5;
--ifm-color-primary-light: #afb7fc;
--ifm-color-primary-lighter: #c2c8fc;
--ifm-color-primary-lightest: #fafaff;
--ifm-color-primary: #F4665C;
--ifm-color-primary-dark: #f24a3e;
--ifm-color-primary-darker: #f13c2f;
--ifm-color-primary-darkest: #e01c0e;
--ifm-color-primary-light: #f6827a;
--ifm-color-primary-lighter: #f79088;
--ifm-color-primary-lightest: #fbbbb6;
}

h1,
h2,
h3 {
font-family: 'PolySans', var(--ifm-heading-font-family);
font-weight: 900;
}

.button {
Expand Down
Binary file added static/fonts/PolySans-Bulky.woff
Binary file not shown.
Binary file added static/fonts/PolySans-Bulky.woff2
Binary file not shown.
Binary file added static/img/absmartly-icon.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified static/img/favicon.ico
Binary file not shown.
Loading