Fluid Scaling: Implementation in SCSS

In Part 1, we learned that the core of our fluid scaling relies on wrapping a target pixel value in a calc() function multiplied by our global ratio variable: calc(VALUE * var(--wp--custom--fxx)).

While powerful, writing out that full calc() string every time we want to define a padding, margin, font-size, or width is tedious and prone to typos. To solve this, we use an SCSS function to write the boilerplate for us.

The fxx() SCSS Function

In our theme’s _functions.scss file, we define the fxx() helper function:

/// Computes a fluid scale based on a provided base value to create proportional, viewport-relative sizing.
@function fxx($value) {
    @return calc(#{$value} * var(--wp--custom--fxx));
}

/// Computes a fluid scale based on a provided base value to create proportional, viewport-relative sizing.
@function fxx($value) {
    @return calc(#{$value} * var(--wp--custom--fxx));
}

How it Works

1. Input ($value): The function takes a single argument. This is simply the pixel value given to you by the designer (e.g., just 24). Notice that we pass it as a raw number, without typing the px unit.
2. Interpolation (#{$value}): This strange looking syntax (#{}) simply tells SCSS: “take the raw number passed into the function and print it here as text”.
3. Output: The function returns the exact calc() string that the web browser needs in order to do the math.

Using fxx() in Practice

This function drastically simplifies our stylesheets. Designers can hand over a 1920px design, and developers can copy the pixel values verbatim, merely wrapping them in fxx().

Without fxx() (Tedious):

.hero-card {
    width: calc(600 * var(--wp--custom--fxx));
    padding: calc(40 * var(--wp--custom--fxx));
    margin-bottom: calc(24 * var(--wp--custom--fxx));
    border-radius: calc(16 * var(--wp--custom--fxx));
}

.hero-card {
    width: calc(600 * var(--wp--custom--fxx));
    padding: calc(40 * var(--wp--custom--fxx));
    margin-bottom: calc(24 * var(--wp--custom--fxx));
    border-radius: calc(16 * var(--wp--custom--fxx));
}

With fxx() (Clean & Maintainable):

.hero-card {
    width: fxx(600);
    padding: fxx(40);
    margin-bottom: fxx(24);
    border-radius: fxx(16);
}

.hero-card {
    width: fxx(600);
    padding: fxx(40);
    margin-bottom: fxx(24);
    border-radius: fxx(16);
}

When Dart SCSS compiles this file (translating our SCSS code into the standard CSS that browsers actually understand), it transforms our clean fxx() calls back into the complex calc() strings.

JavaScript Utility Parity

Sometimes, styles need to be calculated or applied dynamically via JavaScript (for example, setting initial layouts for complex GSAP animations). To maintain consistency, we provide an identical utility in JS (src/js/utility.js):

export const fxx = (value) => `calc(${value} * var(--wp--custom--fxx))`;

// Usage:
// element.style.gap = fxx(20);

export const fxx = (value) => `calc(${value} * var(--wp--custom--fxx))`;

// Usage:
// element.style.gap = fxx(20);

While 

fxx() solves the problem of keeping layouts proportional, pure proportional scaling has a flaw: what happens when a screen gets too small, or too large? We’ll explore how to control these extremes using mathematical bounds in Part 3.