Mixins: CSS variables break when passed to mixin #78

dwighthouse · 2019-05-07T18:45:46Z

Passing CSS variable values to a mixin results in corrupted output. Both color and size type values were tested, with the resulting output of both always being a substring of the input from the start of the string to one character before the paran that is part of the CSS variable syntax. If I had to guess, I suspect that the parser being used doesn't expect parens in mixin params. You can see from the output, that CSS variables are being output correctly through the normal CSS usage, they only get corrupted when passed to a mixin.

Example, using mixin defined in the README:

/* Start: From the README */
@mixin heading-text($color: #242424, $font-size: 4em) {
    color: $color;
    font-size: $font-size;
}

h1, h2, h3 {
    @include heading-text;
}

.some-heading-component > :first-child {
    @include heading-text(#111111, 6em);
}
/* End: From the README */

/* CSS Variables are broken colors (outputs "va") */
.color-variable {
    --my-color: #555;
    @include heading-text(var(--my-color));
    background-color: var(--my-color);
}

/* CSS Variables are broken and sizes too (outputs "va") */
.size-variable {
    --my-size: 20px;
    @include heading-text(#555, var(--my-size));
    margin: var(--my-size);
}

Output:

/* Start: From the README */
h1, h2, h3 {
    color: #242424;
    font-size: 4em;
}
.some-heading-component > :first-child {
    color: #111111;
    font-size: 6em;
}
/* End: From the README */
/* CSS Variables are broken colors (outputs "va") */
.color-variable {
    --my-color: #555;
    color: va; /* <= ERROR */
    font-size: 4em;
    background-color: var(--my-color);
}
/* CSS Variables are broken and sizes too (outputs "va") */
.size-variable {
    --my-size: 20px;
    color: #555;
    font-size: va; /* <= ERROR */
    margin: var(--my-size);
}

I attempted to create a live code example on CodePen, as recommended, but I was unable to figure out how to tell CodePen to use PreCSS (or this plugin specifically) on top of PostCSS. However, my example compiles locally as described through PostCSS (version 7.0.16), which is using the PreCSS plugin (version 4.0.0, latest), which is using postcss-advanced-variables (version 3.0.0, latest). This is run via gulp-postcss (version 8.0.0, latest).

connorjs · 2020-04-12T03:06:57Z

If I had to guess, I suspect that the parser being used doesn't expect parens in mixin params.

@dwighthouse - thanks for this observation. I ran into this problem as well, but was able to use the following workaround: pass the variable name without var and then use var within my mixin. Picking pieces of the example...

@mixin heading-text($color: --my-default-color, $font-size: 4em) {
    color: var($color); /* Use `var` within the mixin */
    font-size: $font-size;
}

.color-variable {
    --my-color: #555;
    @include heading-text(--my-color); /* Pass variable name, no `var` */
    background-color: var(--my-color);
}

It's not the nicest as it passes variable names instead of variables, but it worked for me in the mean-time. It also makes a non-variable default harder. In my case, I didn't need a default value.

t0byman · 2023-01-20T14:54:03Z

Would like a real fix for this though, doubt we'll get one since the last release for this package was February 2018.

kmonahan linked a pull request Feb 27, 2023 that will close this issue

Allow for CSS variables to be used with mixins #96

Open

armano2 mentioned this issue Feb 24, 2024

fix: correct issues with mixin params armano2/postcss-advanced-variables#5

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Mixins: CSS variables break when passed to mixin #78

Mixins: CSS variables break when passed to mixin #78

dwighthouse commented May 7, 2019

connorjs commented Apr 12, 2020

t0byman commented Jan 20, 2023 •

edited

Mixins: CSS variables break when passed to mixin #78

Mixins: CSS variables break when passed to mixin #78

Comments

dwighthouse commented May 7, 2019

connorjs commented Apr 12, 2020

t0byman commented Jan 20, 2023 • edited

t0byman commented Jan 20, 2023 •

edited