refactor: Move ui.Theme.from_brand() Sass code into an .scss file

[gadenbuie]

The main goal is to move as much Sass code and logic out of Python and into a single _brand-yml.scss layer file, building on #1790.

There's a small amount of code insertion that still needs to happen, these places are marked in the Sass file with special comments, e.g.

/*-- scss:defaults --*/

/*-- insert(brand.color.palette:defaults) --*/
/*-- insert(brand.defaults:defaults) --*/
/*-- insert(brand.color:defaults) --*/
/*-- insert(brand.typography:defaults) --*/

As part of this, we now push a set of brand-specific Sass variables and primarily use these to set other values, e.g.

$brand_typography_base_family: Open Sans !default; // optional, added if brand.typography.base.family is present

// ... later ...
$brand_typography_base_family: null !default; // always included to prevent errors

// ... later ...
$font-family-base: $brand_typography_base_family !default; // Set Bootstrap variables

Note that we can't use the null !default set up for the Bootstrap core variables like $primary or $secondary etc. because the null value ends up infiltrating into places where it's not valid.

[cpsievert]

Any chance this could be done with .add_defaults() and .add_rules() instead of ._insert_sass()?

[gadenbuie]

Maybe? But it'd be a quite a bit more complicated and would reduce the portability of the Sass file. Obviously we can't add a new section without writing new Python/R code, but with this implementation we can adjust this Sass file directly without having to then carefully considering the order of operations that need to happen in the Python/R code.

[gadenbuie]

I also like that you can look at the Sass file and have a sense of the pieces that are going to be added.

Also string substitution isn't elegant but it's certainly easy to do in both Python and R and both implementations will basically be the same thing. It's likely that using the Sass layer mechanisms will work out to look pretty similar in both languages, but it certainly increases the context window of things you need to understand.

In other words, I'm going for a solution that, as much as possible, fits into one Sass file.

[gadenbuie]

Anyway, that's what I was thinking but I rewrote it to use standard Sass methods and I don't hate it. 4ddf0f5

[cpsievert]

Maybe let's save this for another PR, but from a quick look, it seems $body-secondary and $body-tertiary don't exist?

[gadenbuie]

There's a good chance I copied this from the Quarto implementation. I'll check.

[gadenbuie]

Yup, came from here: https://github.com/quarto-dev/quarto-cli/blob/bf550cf7049f19d486b7410cb746b70367d0c359/src/core/sass/brand.ts#L31-L34

Happy to leave this for a follow-up PR.

[cpsievert]

I would have expected the ordering here to be swapped (i.e., Bootstrap defaults first since they're the most specific). What's the rationale for the palette coming first?

[gadenbuie]

The goal is to be able to say something like $navbar-bg: $brand-blue, which requires this order:

$brand-blue: "#2233ff";

$navbar-bg: $brand-blue;

[cpsievert]

Ah, ok, that feels worth it. A mention of that capability in the Sass would be great.

[gadenbuie]

idk this feels a lot like the kind of comment that's explained by the code. brand.color.palette is only the brand's named colors and its Sass variables come before brand.defaults because otherwise you couldn't use them under brand.defaults. If it were the other way around, I think it'd need to be commented.

[cpsievert]

Could it be that this is the problem? https://github.com/rstudio/bslib/blob/112efd0e/inst/lib/bs5/scss/_variables.scss#L303

[gadenbuie]

Yup! Fixed in rstudio/bslib#1149