Adding WC Elements to a page breaks the Variable text Styling

I set all my sites to use variable dynamic text as per one of Josh’s videos. In global css i set

:root {
–cs-sm: clamp(0.8rem, 0.08vi + 0.78rem, 0.84rem);
–cs-base: clamp(1rem, 0.23vi + 0.94rem, 1.13rem);
–cs-md: clamp(1.25rem, 0.45vi + 1.14rem, 1.5rem);
–cs-lg: clamp(1.56rem, 0.79vi + 1.36rem, 2rem);
–cs-xl: clamp(1.95rem, 1.29vi + 1.63rem, 2.66rem);
–cs-xxl: clamp(2.44rem, 2.02vi + 1.94rem, 3.55rem);
–cs-xxxl: clamp(3.05rem, 3.06vi + 2.29rem, 4.73rem);
}

On this latest site I’m building it has woocommerce included. Whenever I add a woocommerce element to a page, all the variable sizing breaks on that page only. It all gets set to the same size and when I inspect the text element it shows as variable undefined.

Here is an example of a page with some wc elements added.
https://darrenh275.sg-host.com/customised-composition/

The WC archive and single pages work fine with reading the variable text.

Thanks.

Hey @DesignMunky,

The issue you’re experiencing is possibly caused by a combination of invalid syntax characters and how the Pro Theme (Cornerstone) processes CSS when WooCommerce elements are present.

1. The “Smart Dash” Issue (Primary Cause)

In the CSS snippet you provided, you are using an En-dash () instead of two Hyphens (--).

  • Invalid: –cs-md (This is one long character)
  • Valid: --cs-md (This is two standard hyphens)

If you copied this from a blog or a “smart” text editor, the two hyphens were likely auto-corrected into a single long dash. CSS variables must start with --. When you inspect the element, the browser sees var(--cs-md) but cannot find a matching definition because yours starts with a .

2. The vi Unit & CSS Parsing

You are using the vi (Viewport Inline) unit. While valid in modern browsers, it is a relatively new CSS unit.

  • Why it breaks with WooCommerce: When you add a WooCommerce element to a standard page, Pro Theme triggers a “Dynamic CSS” bundling process. This process often runs your Global CSS through a PHP-based CSS minifier/parser to merge it with WooCommerce’s specific styles.
  • The Problem: Many older CSS parsers (including some used by WordPress themes and plugins) do not recognize vi as a valid unit. When the parser encounters vi, it assumes the line is a syntax error and strips the entire variable definition to prevent the CSS from breaking.

3. Why it works on Archive/Single pages

In the Pro Theme, WooCommerce Archive and Single pages are typically handled by the Layout Builder, while standard pages use the Content Builder.

  • The Layout Builder outputs Global CSS in a “raw” or prioritized state that avoids the specific minification/bundling logic triggered by “Cornerstone WooCommerce Elements” on standard pages.
  • This is why the browser sees the variables on those pages but loses them on standard pages where the stricter parser has “cleaned” them out.

How to Fix It:

  1. Replace all En-dashes: Ensure every variable starts with exactly two standard hyphens (--).
  2. Switch vi to vw: Change vi to vw (Viewport Width). In a standard horizontal website, they function identically, but vw is universally recognized by all CSS parsers and minifiers.
  3. Wrap in calc() if needed: While clamp() handles math, some older parsers prefer complex expressions inside a calc(). However, fixing the dashes and the unit will likely resolve it immediately.

Sample Correct Snippet:

:root {
  --cs-sm: clamp(0.8rem, 0.08vw + 0.78rem, 0.84rem);
  --cs-base: clamp(1rem, 0.23vw + 0.94rem, 1.13rem);
  --cs-md: clamp(1.25rem, 0.45vw + 1.14rem, 1.5rem);
  --cs-lg: clamp(1.56rem, 0.79vw + 1.36rem, 2rem);
  --cs-xl: clamp(1.95rem, 1.29vw + 1.63rem, 2.66rem);
  --cs-xxl: clamp(2.44rem, 2.02vw + 1.94rem, 3.55rem);
  --cs-xxxl: clamp(3.05rem, 3.06vw + 2.29rem, 4.73rem);
}

Hi Christian,

I’m not sure why the two hyphens didnt paste properly when I pasted here from the site but they were correct in the global css.

I tried your sample snippet format and no visible change.
I’m not sure what you meant by wrap in calc if needed. I tried doing it this way without any success either.

:root {
–cs-sm: calc(max(0.8rem, min(0.08vw + 0.78rem, 0.84rem)));
–cs-base: calc(max(1rem, min(0.23vw + 0.94rem, 1.13rem)));
–cs-md: calc(max(1.25rem, min(0.45vw + 1.14rem, 1.5rem)));
–cs-lg: calc(max(1.56rem, min(0.79vw + 1.36rem, 2rem)));
–cs-xl: calc(max(1.95rem, min(1.29vw + 1.63rem, 2.66rem)));
–cs-xxl: calc(max(2.44rem, min(2.02vw + 1.94rem, 3.55rem)));
–cs-xxxl: calc(max(3.05rem, min(3.06vw + 2.29rem, 4.73rem)));
}

Hey @DesignMunky,

Can you create another test page with way fewer elements. Then, provide us a screenshot of the element that’s causing the issue.

Thanks.

Hi Christian,

I’ve created the following test page for you as instructed:

https://chapmusemusic.com.au/test-wc-issue/

Cheers.

Hello @DesignMunky,

I’d like you to understand first how the styling where loaded in your site. There is a heirarchy in loading the styles.

  • Theme stack style.css
  • Child theme style.css
  • WP Additional css (Appearance > Customize > WP Additional CSS)
  • Theme Option Settings
  • Theme Options’s Custom CSS
  • Cornerstone/ Pro Editor page Custom CSS
  • Cornerstone/Pro Global CSS

I recommend removing your CSS from the Global CSS and adding it to Appearance > File Editor > Style.css instead. If that is not accessible, add it in WP Additional CSS (Appearance > Customize > WP Additional CSS).

Kindly let us know how it goes.

Hey Reunel,

Did the job - thanks!

I added the css through WP Additional CSS (Appearance > Customize > WP Additional CSS

Cheers,
Darren

Glad to hear that, Darren.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.