mirror of
https://github.com/snachodog/just-the-docs.git
synced 2025-04-16 16:12:23 -06:00
19dbd776c1
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.
13 lines
408 B
Plaintext
13 lines
408 B
Plaintext
{% if site.logo %}
|
|
$logo: "{{ site.logo | relative_url }}";
|
|
{% endif %}
|
|
@import "./support/support";
|
|
@import "./custom/setup";
|
|
@import "./color_schemes/light";
|
|
{% unless include.color_scheme == "light" %}
|
|
@import "./color_schemes/{{ include.color_scheme }}";
|
|
{% endunless %}
|
|
@import "./modules";
|
|
{% include css/callouts.scss.liquid color_scheme = include.color_scheme %}
|
|
{% include css/custom.scss.liquid %}
|