Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for custom CSS #2

Open
dmi3kno opened this issue Oct 21, 2024 · 1 comment
Open

Support for custom CSS #2

dmi3kno opened this issue Oct 21, 2024 · 1 comment

Comments

@dmi3kno
Copy link

dmi3kno commented Oct 21, 2024

Here's a great example for callout styling
Perhaps some of it could be parameterized from YAML, otherwise, some examples may be provided for styling of custom callouts

@coatless
Copy link
Contributor

I'm aiming to avoid exposing the CSS/SCSS side as much as possible for a couple of reasons:

  1. We want to leaning as heavily as possible on the built-in quarto.Callout node instead of a custom Div as other filters can now pick up the inserted callout.
  2. As we expand to LaTeX, Typst, and other formats, there are going to need to be a cascading amount of effects.

That said, I have a quick note on styling in the FAQ:

https://quarto.thecoatlessprofessor.com/custom-callout/qcustom-callout-faq.html#what-if-i-want-to-change-the-appearance-of-all-my-custom-callouts

I think the better part of valor here would be to add another key like: enable-style: false. This would prevent the extension from running any of the generate*Format() portions in favor of allowing theme information to be loaded through:

format:
  html:
    theme: 
      light: [default, customstyle.scss]
      dark: [darkly, customstyledark.scss]

We'd also probably provide a general list of rules that need to be set via documentation.

Does that sound like a fair trade-off?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants