Added !default to override the variables

[hnla]

Can we briefly use case why this would benefit, Not adverse to adding them but not sure how the !default flag helps despite reading the specs :)

I'm assuming you just want to ensure that you can override these vars with your own values? In terms of this BP theme I tend to regard those as the assigned values i.e the defaults & that creating a new theme or TP would be a case that the dev could re-use the vars and simply change to what they wanted.

[ferdiesletering]

My goal is to override the vars and having the flexibility to change $pad-med without overriding with higher specifity css or change it on multiple places.

My use case is as follows: I'm using a WP theme and have the next-template-packs enabled. In my theme's style.scss file I'm importing custom variables.scss above the buddypress.scss with to override the variables. Another benefit is that I can use $pad-med for other custom styling.

I deregister the 'bp-nouveau' style handle and enqueue my custom css that contains my styling for my project and buddypress.

Basically I'm overriding several templates and styling with next-templates-packs enabled. What's your opinion on this use case?

You guys did a great job with splitting the styling into multiple files!

[hnla]

My overriding thought is that the Nouveau project as it exists currently in plugin guise is only a temporary development process and that it builds out the compiled files at a staging environment point, in much the same way we do with the core templates, thus when the final release version is built the /src/ directory removed Nouveau templates would simply include the real .css files. If then a child theme is created they would need to be overriding vanilla css rulesets and properties such as color: #333; etc as the original scss vars no longer figure and couldn't be overridden.

Of course though I'm aware that there are any number of ways that someone that has deeper knowledge could approach things and it's that which I'm interested in understanding so that we do provide the most flexible approach to being able to customize.

So while I get your use case I think it misses the point in that Nouveau isn't intended to be a plugin, but equally thinking there's no reason it couldn't be used as such, however I think it needs taking into consideration that eventually when you activate BP Nouveau will exist in the core and selected as default templates for new installs, how will that affect things?

The intention with the switcher in BP settings was also to allow further template packs to be added and I guess then those would likely be as standalone plugins, resembling your use case.

Another aspect of all this and why I decided to split those scss partials up in their own /common-styles/ folder was that they represented a base level of styles that could be re-used and extended on ( and why I have styles in a direct scss folder too that are intended to reflect this actual TP specific styles )

Sorry to ramble on and thanks for being patient :) This request does make me consider certain aspects of what we're doing.