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

Base style presets and style transclusion? #89

Open
Omikhleia opened this issue Sep 21, 2024 · 0 comments
Open

Base style presets and style transclusion? #89

Omikhleia opened this issue Sep 21, 2024 · 0 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@Omikhleia
Copy link
Owner

For the reminder, the styling paradigm in re·sil·ient works as follows:

  1. [One possibly manually copies an existing style file from another project to the target name (...-styles.yml)]
  2. One compiles a document and get a [possibly extended] full style file
  3. One adapts the style file (to language dependent usage, to document type specifics, etc.)
  4. One re-compiles the document.

While it works well, I'd like to consider streamlining at least step 1 and 3.

  • Have a repository of sane style fragments, possibly dependent on language (e.g. "fr" footnotes already differently from "en" footnotes)
  • Have a way for (top-level) style files to declare the inclusion of a
  • Have a way to specify main language and a base style as "class" options

This way, one could use stock presets or put their presets in some common folder, and just declare which to use as basis for a specific document.

Ex.

  • Say we have base style "regular" (pick a better name, lol) including a fragment "regular.footnote", and two such fragments "en.regular.footnote" and "fr.regular.footnote"
  • User specifies "fr" as langage and "regular" as base style, and all is resolved appropriately to the best match.

So one could skip point (1) wholly, while immediately obtaining a decent styling (even with variations depending on language and whatnot).
There would be less work then in step (3), and more re-usability eventually.

I am wondering whether the above really makes sense and is a nicer direction vs. what we currently have. Being (as far as I know) the only user of advanced features in my own little collection, maybe I too used to it to see the broader picture. (Hence the "question" label).

@Omikhleia Omikhleia added enhancement New feature or request question Further information is requested labels Sep 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant