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

Change folder structure? #144

Closed
badlydrawnrob opened this issue Aug 4, 2024 · 1 comment
Closed

Change folder structure? #144

badlydrawnrob opened this issue Aug 4, 2024 · 1 comment

Comments

@badlydrawnrob
Copy link
Owner

badlydrawnrob commented Aug 4, 2024

The new version is shaping up ...
Changing habit is difficult!

Why are the folders named that way?

config.less
main.less
/style/modules/mixins/...
/style/modules/variables/*.less
/style/partials/*.less
/style/gps/global/*.less
/style/gps/page/*.less
/style/gps/section/*.less

This will be changed; for now it's just a way to order things getting used to the new css method. Why /modules and not just /variables? I'm not using /mixins anymore so that's the first to go ... why use _root.less twice (once for variables and once to setup base styles.

Some of these are inherited from old frameworks and the parent styles from Print First CSS. We used to also use /themes/cards/missing.less and simple.less as well as a /component folder (ECSS tells us to keep page/component styles together with their main template files).

Anyway, bottom line is these can be simplified. For instance, as GPS #section styles should be nested inside #page styles, they should probably live inside the /pages folder with their parent #page. There's also Anki-specific sections such as #answer which is a #fragment for linking to on the reverse of the page (scrolls this portion into view).

Is #answer classed as a section? Well, I don't know! With GPS there's some fuzzyness to the decision making, whereas with ECSS it'd simply be .just-SomeClass_OrAChild. A proper guide is required for fringe cases.

Potential changes

  • /root or /base for all raw html styles and --css-variables (/partials would live here)
  • /global styles with .gl- classes (or /design-system as we'd need a specimen file to display component styles)
  • /page folder for all individual pages (or they could live with the /page.html inside it's folder)

A note on frameworks

I'm not entirely convinced yet about GPS-style css, but I DO believe in minimalism and increasingly have a brutalist mindset. While it's nice to have a fancy UI, it isn't necessary, and it's a real bugger to maintain and update as the code complexity increases. CSS is definitely not one of the nicest languages to code in.

Footnotes

  1. Some of the rules in ECSS are still worthwhile, such as for gl- sections. It is a bit disconcerting after using this framework for so long to go from .gl-Card_Header (a child of .gl-Card) to simply .gl-Card header. I guess I'd have to train my brain out of that habit. Although BEM might look a little ugly, looking at the class names is habit and the rules of inheritance doesn't really matter as everything is a class. Using GPS you'll have to start thinking about inheritance a bit more.

  2. Is it really necessary to order them by grouping? Is it just easier to list styles alphabetically? Whichever method you choose, aim to be consistent and have your team follow the rules.

@badlydrawnrob
Copy link
Owner Author

This is done in the next release

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

No branches or pull requests

1 participant