Expand to include css vars that are not in :root:

[maxfenton]

This would be a great postcss plugin if it could handle CSS vars that are not in the :root element like https://github.com/nuxodin/ie11CustomProperties/issues can (but not client-side, obviously)

[jonathantneal]

I agree. I am intending to merge these two projects in a manner of speaking.

Note, I am the author of this bug: nuxodin/ie11CustomProperties#57

Note the response, “I would have to have a real CSS parser”: nuxodin/ie11CustomProperties#57 (comment)

Note in the pinned call for maintainers for cssnano, an underlying issue to be resolved in PostCSS:

You can fix problems and improve this great tool. For example postcss/postcss#1145 and postcss/postcss#1299 still not solved and it is you who can help with this.
cssnano/cssnano#833

And I am the author of that bug report:
postcss/postcss#1145

As well as this bug report with a similar conclusion:
postcss/postcss#1349

Unfortunately, I can’t use the tool you’ve suggested until I’ve solved a bug that requires a new CSS parser. This plugin in its current state has a similar need. There are similar bugs in other PostCSS plugins, Webpack, etc. Andrey is hard at work cutting the next release of PostCSS, and the best help I can be — I think — is to write a new parser for the next major release of PostCSS.

---

I am working on this new CSS parser in my spare time. It will resolve all of these underlying bugs.

Unfortunately, nobody has offered time to help me, and it takes time.

Now, I do help as I can along the way. Note, I did get a critical fix into the plugin you requested this week:
nuxodin/ie11CustomProperties#58

This may help Drupal merge this into their core:
nuxodin/ie11CustomProperties#54

Please feel free to continue to ping me. It’s not a bother. Seriously!

I just also want folks to understand why I’m taking time to solve an underlying problem. I feel all of these problems have piled up to the point that my free time is all-but-lost until I write a new parser for PostCSS. With that, I feel my contributions will be more sustainable here and elsewhere moving forward.

[maxfenton]

Wow, thank you @jonathantneal — this is my looks at watch third day of even thinking about this issue as it relates to some clever Tailwind classes and I'm sorry to leap in without having tracked down that history you shared. Thank you so much.

[javier-garcia-meteologica]

It would be nice to allow specifying extra containers. The option would be specified at the time of plugin createion { extraContainers?: RegExp[] }. It would extend the default continer matching regexes.

The file src/lib/get-custom-properties-from-root.js should be modified like this.

// whether the node is a custom container specified by the user
const isCustomContainerRule = (node, extraContainers = []) => 
 extraContainers.some(extraContainerRegExp => node.type === 'rule' && node.selector.split(',').some(item => extraContainerRegExp.test(item)) && Object(node.nodes).length);

The variables captured by these extraContainer regexes could be placed in a third object customPropertiesFromCustomContainers.

 root.nodes.slice().forEach(rule => { 
 	const customPropertiesObject = isHtmlRule(rule) 
 		? customPropertiesFromHtmlElement 
 	: isRootRule(rule) 
 		? customPropertiesFromRootPseudo 
 	: isCustomContainerRule(rule, extraContainers)
 	        ? customPropertiesFromCustomContainers;
 	: null;

And merged like this

 return { ...customPropertiesFromHtmlElement, ...customPropertiesFromRootPseudo, ...customPropertiesFromCustomContainers }; 

Why is this useful? To allow capturing :host, :host([read-only]), etc. depending on what the user wants.