Misago's default style is build with Bootstrap 3.6, but some parts of the UI are using flexbox instead of bootstrap grid.

I really want to update Misago to something else. My first choice was Bootstrap 5 or maybe even 6 if that one ships before I will hit my other long term dev targets: removal of React from Misago and putting the featureset up to snuff. So obviously, whats planned here is 2025-2026 material.

In past I've glossed over the Tailwind because I just couldn't wrap my mind around how one could write a styles system on it that would let a site authors to write custom styles.

I've found an answer in style variables.

New styles system

Each style in new system would include:

• a full Tailwind CSS build
• zero or more extra SASS files with additional CSS
• style variables
• extra assets

Lets go through those:

A full Tailwind CSS build

Misago will provide a default build of Tailwind CSS for style authors to use. If you are unhappy with that, your style will be able to override it with a custom build instead.

SASS files

This won't be used by a default style, but each style in Misago will be able to define extra CSS to use with SASS. SASS is a CSS preprocessor that supports CSS syntax but also extends it with new elements, making it more comfortable to write

Style variables

This is a biggie. Misago will define a list of style variables that template authors will be able to use in their templates. For example, navbar variable would hold values of class="..." HTML attribute of the forum navbar. Because Misago would be using Tailwind, default style would put md:container md:mx-auto d-flex p-4 mb-8 into it.

This may sound scary, but please keep on mind that style inheritance system will be put in place. If you leave this variable empty in your style, its value will be inherited from a parent style (which in practice will mean it will inherit its a value from Misago's default style). Likewise if you want to use parent's variable value, but also add extra values, you could input super extra-class other-class and styles system would substitute super for inherited classes.

Misago would still provide classic CSS classes on per-page basis for the developers to use in custom CSS.

We could also provide variable reuse so style could have a variable. btn_primary value thats not used anywhere in a template but editor_submit_btn variable could do var:btn_primary in it's value to reuse its value.

Extra assets

Additional assets are image or font files that style may use as backgrounds or custom icon fonts, etc, ect.

It would be insane to display a list of 2137 inputs in Misago's admin to style authors, so style vars will have to be grouped and potentially sub-grouped. Interesting side-effect of this approach would be that now we would be able to display a proper theme editor where you could click on a "Post" on the list of components to edit styles for and get a half of the page taken by a preview of a post and other half with inputs for variables for you to edit.

Also a thing to keep on mind that Tailwind is pure CSS framework, and I will have to re-implement dropdowns and modals using custom JS. But this JS is simple enough to write yourself, and I can always look at Bootstrap's current JS for reference.

One more thing: Tailwind is 2.5mb uncompressed. Misago will have to implement a CSS pruner like the one that Tailwind already uses.

Luckily Python already has a working and maintained CSS parser: tinycss2

That was a lie. Tailwind 3 first gathers a list of all used names in a project, and then does a cartesian product of possible class names, skipping those that don't appear on the list. Not a fan of this, but I'll have to run Node within a container to do Tailwind builds. Luckily I will be able to limit this only to the celery-worker container, and only running Node on demand, when style changes.

Tailwind 4 may run without Node.js, seeing how it's all written in Rust now. That would be ideal for Misago because SASS is also implemented in C and doesn't require Node to run. We could have first build step that would generate source files for Tailwind from Misago's templates and style's CSS/SASS files together with style variables. Then call Tailwind to compile it all into final CSS file.

From my understanding Tailwind v4 still relies on node.js and npm to work, so we'll still have to install node.js in container. This is meh, but there is space for it, and it will only run if needed, within the Celery Worker container.

Also, I still need a plan on migrating from bootstrap to Tailwind. The simplest solution I see is to create a branch that will take 6-12 months to complete that just rewrites entire Misago from Bootstrap 3 to Tailwind 4, but I am trying this currently with Misago 0.40 for other things and I think we agree that stopping large releases for potentially a year is a terrible thing to do and I want to avoid this as much as I can in the future.

I've been thinking about how we can do this incrementally and here's idea I am liking the most:

1. Implement support for style variables in Misago: this will include default style vars, final style vars compilation (in Python) and admin UI for editing style vars.
2. Write a css generator, nicknamed "Crosswind", that will generate a CSS classes identical to ones implemented by the Tailwind, with key differences that it will only generate styles needed by Misago (colors, margins, paddings, borders, etc, ect). This file will still be big, but not many megabytes big.
3. Move parts of Misago to new approach:
   1. Select part of Misago
   2. Create new style vars
   3. Update CSS generator if needed
   4. Update templates to use the style vars
   5. Delete old unused CSS classes
   6. Update JS if needed
   7. Merge changes to the main
   8. Rinse and repeat
4. When no Bootstrap styles are left in Misago:
   1. Add Node.js with Tailwind to Misago containers
   2. Deprecate misago.themes
   3. Create misago.styles, based on misago.themes but integrated with Tailwind (eg. options to configure Tailwind theme, use @apply in your CSS files)
   4. Add management command and celery task with admin UI for rebuilding style's CSS when admin edits style vars
   5. Remove the Crosswind
5. ???
6. Profit

I can't wait to implement this, but first I'll have to remove all of of React.js (and Moment.js) from the codebase. But after that, I could work on implementing parts 1-3 of the plan, and from then on swing between implementing new features using this approach, or moving existing features to it.