In the conversation for #1166, I noticed that the import order for `setup.scss` disagrees with our docs.
> In particular, the [docs for `setup.scss`](https://just-the-docs.com/docs/customization/#override-and-define-new-variables) reads:
>
> > To define new SCSS variables, functions, or override existing theme variables, place SCSS code in `_sass/custom/setup.scss`
>
> But, this is not true - `setup.scss` is loaded *before* all of the themes, so it doesn't override existing theme variables.
>
> In my opinion, the solution here is to move `setup.scss` after all the `color_scheme` SCSS. This way, `setup.scss` properly allows theme overrides. In addition, users who previously defined variables in `setup.scss` and then used them in their custom color schemes can shift those declarations to be entirely in the theme code.
This is a one-liner that fixes the behaviour to be in-line with what our docs state.
This is a deceptively simple PR that stops the double import of `color_schemes`. With @pdmosses' stellar suggestion, it's a simple two-liner!
## interaction with #1166
This is a clean merge!
## path forward for default syntax highlighting
However, this leaves an interesting question: if the user doesn't provide syntax highlighting as part of their color scheme, should we include a default set (in this case, the light theme)?
Broadly, I see a few arguments:
1. if we don't provide defaults, we'll break color schemes that don't define their own syntax highlighting
2. if we do provide defaults, we could unnecessarily bloat the file size
I think 1 is more pernicious than 2. Thus, my suggested path forward is:
- for now, merge this
- in `v1.0`, separate these concerns properly, and force each color scheme to provide its own syntax highlighting CSS. Provide a default file for users to import with `@import` or `@use`[^1].
[^1]: Separately, we're using `!default` wrong; [looking at the docs](https://sass-lang.com/documentation/variables#default-values), we need to be using it with `@use` for the defaults to take effect. Since we're not doing that, `!default` isn't actually doing anything! This is why variable overrides aren't propagating the way they should be (and thus, users need to do a lot of duplication). Fixing this is probably a v1 item, though I'll have to think about it more.
This is an alternative PR that resolves#1011. Unlike #1013, this PR defines a *new* SASS file, `_sass/custom/setup.scss`, specifically designed for new custom variables (and other SASS-only constructs). It's imported after our `support` SASS files are (functions, variables), but otherwise is imported before all other files (ex, when CSS is emitted).
So, custom callout colors can now be defined in this file. I also move the custom callout colors present in `custom.scss` to the right location.
I've added some docs that briefly explain how to use the feature. Feedback is welcome!
---
As an aside, I chose not to add a `_includes/css` file that imports this, and then import that file. I think that's only necessary if we're trying to render liquid somehow in the SASS file; since we're not trying to do that for `setup.scss`, I've opted to not include it. If we think this is relevant, I can re-add it.
Co-authored-by: Peter Mosses <18308236+pdmosses@users.noreply.github.com>
* Fix default highlighting in custom schemes
Fix#982
The variable settings for highlighting in the default `light` scheme are currently (v0.4.0.rc2`) in `_sass/color_schemes/light.scss`.
This PR ensures that custom schemes are based on the `light` scheme.
It also adds a note explaining the default to the customization docs,
and gives an example of how to define a custom scheme based on the `dark` scheme
* Prettier
* Deleted test file
Co-authored-by: Matt Wang <matt@matthewwang.me>
