digitalfabrik / integreat-cms

Simplified content management back end for the Integreat App - a multilingual information platform for newcomers
https://digitalfabrik.github.io/integreat-cms/
Apache License 2.0
55 stars 33 forks source link

Meta-css-classes for UI elements #172

Open timobrembeck opened 5 years ago

timobrembeck commented 5 years ago

Currently, we use sets of ~10 css classes per UI element. If we want to make small changes to the elements (e.g. change the appearance of all buttons), we have to change these classes in all buttons in every template manually. This is not practically, thus we need some kind of meta-classes to bundle these stylings and can be managed centralized: https://tailwindcss.com/docs/functions-and-directives

Here is a good guide on how to achieve de-duplication of css classes: https://tailwindcss.com/docs/extracting-components

sascha11110 commented 4 years ago

Should be fixed by https://github.com/Integreat/cms-django/commit/645dbf4ae4fb531306ff79232e9e2f55e235c915

timobrembeck commented 4 years ago

Actually, I meant something else by this issue: At the moment, we use certain combinations of css classes very often. I would like to add meta-classes which compile to a set of classes, so we have like "integreat-input-field" and "integreat-button", and when we want to change the appearance of all buttons, we only have to change this meta-class... do you know what I mean? Is that possible?

The commit you're mentioning fixes #280.

timobrembeck commented 3 years ago

I started working on this on the branch feature/tailwind-css... So anyone interested in this issue can continue there.

svenseeberg commented 3 years ago

I think we should postpone this to the Additional Features milestone. We do not have any problems with the current status.

timobrembeck commented 3 years ago

That would be fine with me. Just for reference: Here is a good guide on how to achieve de-duplication of css classes: https://tailwindcss.com/docs/extracting-components TL;RD: Try to extract components into sub-templates first (e.g. centralized form/field templates), only use meta-classes where strictly necessary (e.g. for small UI elements like buttons).