Use `!default` variables in components to allow easier overrides

[RossMcMillan92]

Hey,

I'm working on a project where we need to override some colours in the govuk components.

Button for example: https://github.com/alphagov/govuk-frontend/blob/master/src/components/button/_button.scss

// _button.scss
$govuk-button-colour: #00823b;
$govuk-button-hover-colour: darken($govuk-button-colour, 5%);
$govuk-button-shadow-colour: darken($govuk-button-colour, 15%);
$govuk-button-text-colour: govuk-colour("white");

Since these variables don't have the default flag, to override the button colours we need to do:

@import 'govuk-frontend/components/button/button';

.govuk-button {
  background-color: $custom-color;
  box-shadow: 0 $button-shadow-size 0 $custom-shadow-color;
  // etc...
}

This is prone to human-error as we need to copy all class names and specific rules. Ideally, with default flags, we'd be able to do the following which is much safer:

$govuk-button-colour: $custom-color;
$govuk-button-hover-colour: $custom-color;
$govuk-button-shadow-colour: $custom-color;
$govuk-button-text-colour: $custom-color;

@import 'govuk-frontend/components/button/button';

I see default flags are set up for the global variables under /settings, but is there a reason they're not set up for component variables? If not, I'd be more than happy to submit a PR to change this.

Thanks!

[NickColley]

Hey Ross,

We're thinking about enabling theming (or white-labelling) in the future but one of the blockers to this right now is not just adding !default to the current variables.

Variables without !default are considered private, this means if we change them we cannot make a breaking change for our users.

If we were to add !default with the variables as they currently are we'd then making them public as part of our API.

This is not the best idea right now since they're all very inconsistent, which means we'll need to change them again with a breaking change forcing projects to change their code.

We do want to make sure we expose overridable variables in a consistent way across the framework in the future...

But this would require thinking about these default variables system-wide on how theming is done which may not be possible just by adding !default for specific components.

You can follow our roadmap for that work by subscribing to this issue: https://github.com/alphagov/govuk-design-system/issues/777

Which is part of our roadmap for the GOV.UK Design System: https://github.com/orgs/alphagov/projects/5?fullscreen=true

[RossMcMillan92]

Thanks for the explanation Nick, that seems reasonable. We'll continue manually overriding for now.

Cheers

[wilsond-gds]

I got a little bit stuck while trying to re-use variables from a .scss file when extending the behaviour of the button styling. There were some variables I wanted that were in the global scope, so I had no problems referencing those in my own code. Things started getting complex when I started trying to reuse the variables that were created like this:

@include govuk-exports("govuk/component/button") {
  $govuk-button-colour: $govuk-button-background-colour;
  $govuk-button-hover-colour: govuk-shade($govuk-button-colour, 20%);
  $govuk-button-shadow-colour: govuk-shade($govuk-button-colour, 60%);
  $govuk-button-text-colour: $govuk-button-text-colour;
  // more code
}

I didn’t initially understand what the @include syntax was doing here, and that the include also meant that these variables would be created in a local scope, so they would be unavailable to me (I spent a few hours trying to see if there was a syntax in SASS that would allow this). The solution I eventually decided on was to use the global variables where I could and recreate my own versions of the colours I wanted to use in my button, with a comment linking back to the original definition of the colours.

I think it would be useful for some or all of the variables a component creates to be available to developers writing their own SASS, if only for consistency?