Some SCSS variables ending up as text in CSS files

[danielfdickinson]

Description

Some SCSS variables are not being replaced during libsass processing and are ending up as text in the CSS. Found via W3 validator in CSS mode.

E.g. this is in the main.<cache-buster>.css:

  [data-bs-theme="dark"] .table-dark, [data-bs-theme="dark"] table,
  [data-bs-theme="dark"] [data-bs-theme="dark"] table {
    --bs-table-color: inherit;
    --bs-table-bg: $body-bg-dark;
    background: #17181c;
    border-color: #23262f; }

Steps to reproduce

1. Set up a test site
   1. npm create thulite@latest thulite-css-validation-test -- --template doks
   2. cd thulite-css-validation-test
   3. npm install
   4. Start the hugo server: npm run dev
   5. Browse to the CSS
      1. In your browser 'view-source'
      2. Click on the 'main.<hash>.css' link.
      3. OR use your browser developer tools and set to NOT display source.
   6. Search for $body-bg-dark.
   7. Observe it is present in the 'live' CSS.
   8. Cancel the server (Ctrl-C)
   9. Build the site: hugo --gc
2. Obtain and install W3 Nu Validator
   1. Download the latest release from
      https://github.com/validator/validator/releases
      1. E.g. wget https://github.com/validator/validator/releases/download/latest/vnu.jar
   2. Ensure you have a recent-ish Java JRE (I use openjdk-17-jre from Debian 12 'Bookworm')
3. Use the Validator and observe the results
   1. Execute java -jar ./vnu.jar --skip-non-css $(find public -name '*.css' | tr $'\n' ' ')
4. Go to the file and line containing an error like error: CSS: “color”: Parse Error.
   • In our case, these are usually unprocessed variables.

Test repo at: https://github.com/danielfdickinson/thulite-css-validation-test

Expected result

CSS files should contain only valid CSS.

Actual result

CSS files contain unprocessed SCSS variables.

Environment

hugo v0.148.2-40c3d8233d4b123eff74725e5766fc6272f0a84d+extended linux/amd64 BuildDate=2025-07-27T12:43:24Z VendorInfo=gohugoio
10.9.2

Additional notes

I do not have a fix for this yet, won't be immediately adding a PR.

Also, on further review it appears other SCSS processing is not behaving as expected
when there are CSS variables involved (e.g. setting a --css-variable-as-property: value). Not sure if this a bootstrap or sass issues (dartsass as transpiler produces the same errors).

[danielfdickinson]

Another bit of code that has a similar issue is this (from components/_expressive-code.scss):

.expressive-code .ec-line span[style^="--"]:not([class]) {
    color: var(--0, inherit);
    font-style: var(--0fs, inherit);
    font-weight: var(--0fw, inherit);
    text-decoration: var(--0td, inherit);
}

Except I am not quite sure what it is supposed to be doing. It doesn't do it as it ends up rendered as:

.expressive-code .ec-line span[style^="--"]:not([class]) {
  color: var(0, inherit);
  font-style: var(0fs, inherit);
  font-weight: var(0fw, inherit);
  text-decoration: var(0td, inherit); }

[danielfdickinson]

I don't see how one would get a ec-line class from Hugo's Chroma highlighter. Does this reference some legacy dependency / framework from Hyas days? (e.g. Doing node-based syntax highlighting using expressive-code package)?

In that case, these references could simply be removed.

[h-enk]

I notice this behaviour only in development — in production it all renders fine for me (all variables get replaced).

Using the W3C CSS Validation Service:

• main.dev.css.txt fails with 25 errors (and 253 warnings)
• main.prod.unminified.css.txt validates OK (no errors and no warnings)

(dartsass as transpiler produces the same errors).

Not tested it myself. I guess a Hugo thing then?

Note, setting/changing a variable works in development, For eample add to assets/scss/common/_variables-custom.scss:

// Put your custom SCSS variables here

$body-bg-dark: yellowgreen;

[h-enk]

I don't see how one would get a ec-line class from Hugo's Chroma highlighter. Does this reference some legacy dependency / framework from Hyas days? (e.g. Doing node-based syntax highlighting using expressive-code package)?

In that case, these references could simply be removed.

Yeah, the (S)CSS could definitely be optimized — something for a rainy Sunday afternoon I guess

[danielfdickinson]

I did some checking - I think there is CSS being removed by the postCSS step in production. When I did some test fixes, it changed some of the colour results and the CSS I expected to be there was, instead of missing.

I plan on working up a PR at least for you to see what I mean.