postcss-color-functional-notation unexpectedly not working

[satouriko]

Bug description

Hi there, I found that with the default postcss-preset-env, case

.text-link {
  --tw-text-opacity: 1;
  color: rgba(87 107 149 / var(--tw-text-opacity));
}

will be downgrade by custom-properties to

.text-link {
  --tw-text-opacity: 1;
  color: #576b95;
  color: rgb(87 107 149 / var(--tw-text-opacity));
}

and will not further downgrade by postcss-color-functional-notation to

.text-link {
  --tw-text-opacity: 1;
  color: #576b95;
  color: rgba(87,107,149,var(--tw-text-opacity));
}

after postcss-color-functional-notation@5.0.2 because of #835

This makes users between the gap (e.g Chorme 49~64) cannot display color correctly, and there seems no option to override

https://caniuse.com/css-variables
https://caniuse.com/?search=space-separated

Source CSS

.text-link {
  --tw-text-opacity: 1;
  color: rgba(87,107,149,var(--tw-text-opacity));
}

Expected CSS

.text-link {
  --tw-text-opacity: 1;
  color: #576b95;
  color: rgba(87,107,149,var(--tw-text-opacity));
}

Actual CSS

.text-link {
  --tw-text-opacity: 1;
  color: #576b95;
  color: rgb(87 107 149/var(--tw-text-opacity));
}

Does it happen with npx @csstools/csstools-cli <plugin-name> minimal-example.css?

N/A

Debug output

No response

Extra config

No response

What plugin are you experiencing this issue on?

PostCSS Color Functional Notation

Plugin version

5.0.2

What OS are you experiencing this on?

No response

Node Version

v16.15.1

Validations

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Would you like to open a PR for this bug?

• I'm willing to open a PR

[romainmenke]

Hi @satouriko,
Thank you for reaching out about this!

Can you share your PostCSS config?

What I see in the playground :

/* source */
.text-link { 
  --tw-text-opacity: 1; 
  color: rgba(87,107,149,var(--tw-text-opacity));
}

/* becomes */
.text-link { 
  --tw-text-opacity: 1; 
  color: rgba(87,107,149,1); 
  color: rgba(87,107,149,var(--tw-text-opacity));
}

const postcssPresetEnv = require('postcss-preset-env'); // v8.4.1

module.exports = {
	plugins: [
		postcssPresetEnv({
			"browsers": [
				"> 0.2% and not dead"
			]
		})
	]
}

---

Where does color: #576b95; come from?
This is not from postcss-custom-properties?

[satouriko]

Hi @romainmenke, sorry for the trouble of understanding. color: #576b95; comes from the optimizer. Let me express it again, with the default configuration (postcssPresetEnv())

/* source */
.text-link { 
  --tw-text-opacity: 1; 
  color: rgb(87 107 149 / var(--tw-text-opacity))
}

/* becomes */
.text-link {
  --tw-text-opacity: 1;
  color: rgba(87, 107, 149, 1);
  color: rgb(87 107 149 / var(--tw-text-opacity))
}

The problem is the same, rgba(87, 107, 149, 1) and #576b95 are just equivalent. rgba(87,107,149,var(--tw-text-opacity)) won't be generated and users falling to the gap (e.g Chorme 49~64) will have a downgraded experience.

[romainmenke]

Hi @satouriko,

No trouble at all :)

Which version of postcss-preset-env do you currently have?

[satouriko]

8.4.1

[romainmenke]

I'm sorry @satouriko, I totally misread one of your first comments and was testing with an incorrect snippet!

I see the issue now and will investigate further :)

[romainmenke]

I think I am on to something :

.test-property-with-var {
	--opacity: 1;
	color: rgba(87 107 149 / var(--opacity));
}

becomes :

.test-property-with-var {
	--opacity: 1;
	color: rgba(87, 107, 149, 1);
}

@supports (color: rgba(0 0 0 / 0)) and (top: var(--f)) {
.test-property-with-var {
	color: rgba(87 107 149 / var(--opacity));
}
}

This does not make it possible to have color: rgba(87, 107, 149, var(--opacity)) for Chrome 49~64 but every visitor will have a good fallback value.

[satouriko]

Wouldn't that end up with a wrong render result if --opacity is overridden by another selector? Since we have color: rgba(87, 107, 149, 1) instead of color: rgba(87, 107, 149, var(--opacity)). Custom properties' document says it only takes css variables definitions in html and :root and the same block.

Currently I find the only way to work around this is to set custom properties to { preserve: false } which would turn off the polyfill if not confident enough.

[romainmenke]

Couple of thoughts :)

If you want rgba(87 107 149 / 1) then you should write that and not rgba(87 107 149 / var(--tw-text-opacity)). If Tailwind makes that impossible you should open an issue with them :)

---

Custom properties' document says it only takes css variables definitions in html and :root and the same block.

The plugin only looks within the same block when { preserve: true }.

.text-link {
  --tw-text-opacity: 1;
  color: rgba(87, 107, 149, var(--tw-text-opacity));
}

becomes :

.text-link {
  --tw-text-opacity: 1;
  color: rgba(87, 107, 149, 1);
  color: rgba(87, 107, 149, var(--tw-text-opacity));
}

but it will never be :

.text-link {
  --tw-text-opacity: 1;
  color: rgba(87, 107, 149, 1);
}

---

Wouldn't that end up with a wrong render result if --opacity is overridden by another selector? Since we have color: rgba(87, 107, 149, 1) instead of color: rgba(87, 107, 149, var(--opacity)).

This is a feature, not a bug :)

Your source has a var(), removing it would alter your source code.

.text-link {
  --tw-text-opacity: 1;
  color: rgba(87, 107, 149, var(--tw-text-opacity));
}

This snippet in modern browsers is dynamic and setting a different value for var(--tw-text-opacity) will have an effect. If one of our plugins removed this behaviour it would be a bug, not a feature.

I know that you can set { preserve: false } for custom properties, but then it will no longer use values from the same block. It will only look at the root.

---

There is no practical difference (as far as I know) between these two :

/* A : the result you expected */
.text-link {
  --tw-text-opacity: 1;
  color: #576b95;
  color: rgba(87,107,149,var(--tw-text-opacity));
}

/* B : our proposed solution */
.text-link {
  --tw-text-opacity: 1;
  color: rgba(87, 107, 149, 1);
}

@supports (color: rgba(0 0 0 / 0)) and (top: var(--f)) {
  .text-link {
    color: rgba(87 107 149 / var(--tw-text-opacity));
  }
}

Is there an example where the last two snippets do not produce the same style?
Maybe I am overlooking something :)

---

It is also important to keep in mind that these are fallback values, to be used as graceful degradation.

Anything with custom properties is very difficult to handle because only in a browser do you know the real values.

Our goal is to set fallback values that are known to be correct.
It is not our goal to try and bring the client side behavior of dynamic custom properties to a build tool.

[satouriko]

There's sure a difference.

I created an example website: https://valuable-powder.surge.sh

On modern browsers (expected):

Tested on Chrome 64 (unexpected downgrade)

https://live.browserstack.com/dashboard#os=OS+X&os_version=Monterey&browser=Chrome&browser_version=64.0&zoom_to_fit=true&full_screen=true&url=www.google.com&speed=1

[satouriko]

What you said a lot about custom properties is irrelevant to the issue. The issue is
postcss-color-functional-notation, i.e rgba(87 107 149 / var(--tw-text-opacity)) -> rgba(87, 107, 149, var(--tw-text-opacity)) is expected to function regardless of the custom properties polyfill

[romainmenke]

Please re-read my last comment :)

I did not say there is no difference at all.
I also did not say that it was impossible to construct an example that shows a difference.

I meant that there is no practical difference between your proposed solution and ours for your specific use case. And specifically no difference between how elements with different classes are styled, not between browser versions. Different techniques will work differently across browser versions.

---

You opened an issue stating that you wanted this source to give a color of rgba(87, 107, 149, 1) in as many browsers as possible :

.text-link {
  --tw-text-opacity: 1;
  color: rgba(87 107 149 / var(--tw-text-opacity));
}

You explicitly stated that you wanted the opacity of 1.
Or did you mean the opposite and was this lost in translation? :)

The solution I proposed gives you exactly that.

Anything else is not an option for us :/
It is either taking the plugins in a direction we do not want or it will cause problems for many other people.

---

If you want the dynamic nature of custom properties, as you showcased in your last example, you should not be targeting browsers without native support.

What you said a lot about custom properties is irrelevant to the issue.

It is extremely relevant, in fact, it is the core of the issue :)
If the postcss-custom-properties plugin didn't exist or wasn't included in postcss-preset-env you wouldn't have this issue.

We have to take the existence of this plugin into account.
It is this plugin that generates this fallback : color: rgba(87 107 149 / 1);.

This plugin needs to do this and it needs to be done first, before any other plugin.
Changing this would be a breaking change for millions of users.

Once color: rgba(87 107 149 / 1); exists as a fallback, it no longer makes much sense to generate .color: rgba(87, 107, 149, var(--tw-text-opacity));.

[romainmenke]

Without postcss-custom-properties :

.text-link {
  --tw-text-opacity: 1;
  color: rgba(87 107 149 / var(--tw-text-opacity));
}

becomes :

.text-link {
  --tw-text-opacity: 1;
  color: rgba(87, 107, 149, var(--tw-text-opacity));
}

[romainmenke]

Please make sure to also try this CSS in Chrome 63 :

.text-link {
  --tw-text-opacity: 1;
  color: #576b95;
  color: rgba(87 107 149 / var(--tw-text-opacity));
}

The text then suddenly becomes black :

[satouriko]

Let me try it again, I don't think you understand the issue I'm saying.

/* source */
.text-link {
  --tw-text-opacity: 1;
  color: rgba(87 107 149 / var(--tw-text-opacity));
}

/* desired */
.text-link {
  --tw-text-opacity: 1;
  color: rgba(87, 107, 149, 1); /* <- this 1 is fallback and might not be correct */
  color: rgba(87, 107, 149, var(--tw-text-opacity)); /* but we have comma separated, Chorme 49~64 happy */
}

/* actually get */
.text-link {
  --tw-text-opacity: 1;
  color: rgba(87, 107, 149, 1); /* <- this 1 is fallback and might not be correct */
  color: rgba(87 107 149 / var(--tw-text-opacity)); /* however we have space separated, Chorme 49~64 unhappy */
}

Why this makes difference? Because suppose there's another rule

.text-link.opacity-10 {
  --tw-text-opacity: 0.1;
}

On browsers between the gap (e.g Chorme 49~64), the "desired" output can render opacity (0.1) correctly, while the "actual" output cannot.