Conversation
| `fu-color` = "#4758AB !default", | ||
| `border-radius` = "1rem !default", | ||
| `navbar-light-color` = "rgba($fg, 0.8) !default", | ||
| `navbar-light-hover-color` = "rgba($fg, 0.9) !default" |
There was a problem hiding this comment.
I can't use $body-color here as I get the error that it's not defined, but it's actually what I'd want to do.
There was a problem hiding this comment.
This seems more correct to me:
`navbar-light-color` = "rgba(color-contrast($navbar-bg), 0.8) !default",
`navbar-light-hover-color` = "rgba(color-contrast($navbar-bg), 0.9) !default",|
Questions
# map either secondary OR fg, bg to component-active-bg
# and also dropdown-link-active-bg
# unless a value was set by the userI am guessing from the convo that we might change this logic. Now, if we didn't change that logic, how would that work with this new code? I.e. the current code differentiated between "secondary from BS defaults" and "secondary from user settings". |
Yes! And you should be able to avoid all the
I'm currently thinking #1682 (comment) which could be done by adding another default with a "hard coded" color pkgdown_bslib_defaults <- function() {
list(
...,
"list-group-active-bg" = "gray !default"
)
}As for other defaults that may want to know what the "final" bg, fg, etc. is, you may have to use a pattern like: theme <- bslib::bs_theme(
version = bs_version,
bootswatch = bootswatch_theme
)
# if pkgdown wants to set new Bootstrap variable defaults based on other Bootstrap variables, you should pass the theme with user defaults added at this point
vars <- pkgdown_bslib_defaults(
bslib::bs_add_variables(theme, !!!pkg$meta$template$bslib)
)
# but still add _your_ defaults first before the user's
theme <- bslib::bs_add_variables(theme, !!!vars)
theme <- bslib::bs_add_variables(theme, !!!pkg$meta$template$bslib)
...
pkgdown_bslib_defaults <- function(theme) {
vars <- bs_get_variables(theme, "fg")
list(
...,
"foo" = vars[["fg"]]
)
} |
Thanks to @cpsievert's feedback
Cc @apreshill