Couple of thoughts here:

Backwards compatibility:

This is likely a pretty big breaking change as projects use variable names directly. It's worth doing but we might want to look at a backwards compatible way of changing things, so we can still keep aliases of the old names around.

Naming conventions:

I wonder if we should use a simpler naming convention here rather than a BEM inspired one. From the Sass docs:

💡 Fun fact:
Sass variables, like all Sass identifiers, treat hyphens and underscores as identical. This means that $font-size and $font_size both refer to the same variable. This is a historical holdover from the very early days of Sass, when it only allowed underscores in identifier names. Once Sass added support for hyphens to match CSS’s syntax, the two were made equivalent to make migration easier.

— https://sass-lang.com/documentation/variables

This means that the following are all equivalent:

$cads-language__background-colour--hover
$cads_language--background-colour__hover
$cads_language_-background-colour-_hover
$cads_language__background-colour__hover
$cads-language--background-colour--hover

Based on this I wonder if a simple hyphen based naming convention would make sense? e.g. $cads-language-background-colour-hover. Would minimise the number of possible variations.

Just realised this was still draft 🙈 carry on.

@davidrapson Tests are now working so PR is undrafted 🎉

• backwards compatibility - you're absolutely right. I've added a bit more information in the description about next steps for this PR
• naming conventions - I see your point, tbh I wouldn't normally bemify variable names. In my opinion thought this can be a good case for using BEM as it makes the variables easier to read and follow. It also makes it easier to keep colours consistent in the future - if a dev needs to add a new colour, they would need to follow the naming convention. Happy to have a further chat

naming conventions - I see your point, tbh I wouldn't normally bemify variable names. In my opinion thought this can be a good case for using BEM as it makes the variables easier to read and follow. It also makes it easier to keep colours consistent in the future - if a dev needs to add a new colour, they would need to follow the naming convention. Happy to have a further chat

Yeah, we also technically use a BEM-ish style now. So maybe the difference I mentioned isn't a big deal? I think as long as we have a consistent pattern that's the most important thing. Another route might be to do something with maps (see https://github.com/biglotteryfund/blf-alpha/blob/master/assets/sass/_vars.scss#L70-L104) and write a helper function to access colours (https://github.com/biglotteryfund/blf-alpha/blob/master/assets/sass/_functions.scss#L12-L14)

Using a wrapping function might help with backwards compatibility as this is how GDS do things too https://github.com/alphagov/govuk-frontend/blob/main/src/govuk/settings/_colours-applied.scss#L33

@davidrapson those links are super useful, thank you! I'll have a further think about how to structure the colours, I'm beginning to lean towards the blf approach as it seems quite clean to me. I'll also think about how to simplify the header/footer colours without wiping the theming functionality. For now I'll move the PR back to draft but will let you know when I reopen it.

🚀 Netlify deployed ca-design-system as draft

https://6242ebf86b0e475cec39db8e--ca-design-system.netlify.app

🚀 Netlify deployed ca-design-system as draft

https://6242ee96e235c863306301b6--ca-design-system.netlify.app

🚀 Netlify deployed ca-design-system as draft

https://624ff7f5f30f81503e95c298--ca-design-system.netlify.app

Closing this as the PR is very stale (pre Storybook removal). I'll raise a new PR with the updated files