Changing Foundation CSS for Tailwind

[andreslucena]

Together, Product and Populate (in charge of the current redesign) have been talking internally about the possibility of changing the CSS framework, and evaluating Tailwind as the new option.

Arguments in favor of Tailwind and/or changing to a new framework

1. Even though initially adding lots of HTML classes seems like a bad idea, it actually works pretty well in practice once you get used to it. For newcomers, we anticipate resistance, but in our experience you get used to it quickly, and once you do, it feels very natural and agile, as you avoid jumping between the HTML and the CSS files. You can see the reasoning behind this on the blog post by Tailwind CSS founder at CSS Utility Classes and "Separation of Concerns"
2. Tailwind abstracts the use of normal and more advanced CSS techniques to a super-simple markup. This means, any developer can make use of more advanced techniques very easily (i.e., adding a gradient between two custom colors only requires this: bg-gradient-to-r from-cyan-500 to-blue-500)
3. Tailwind relies a lot on browser standards. This means that changing custom colors of a site (defined in the admin) to Tailwind is very easy and would work out of the box, with all the advantages of Tailwind
4. Tailwind is a young but consolidated project, getting lots of traction in recent years. They have a sustainable and very healthy business model. The probability of Tailwind development stopping is very low (and even then, current tools are huge, which would give us runway to use modern CSS techniques). As we've talked before, Foundation at the moment has stagnated. See more about Foundation below.
5. Tailwind don't impose any specific visual style, and the customization of default values (for scales, colors, etc.) is very powerful and easy
6. Related to the discussion of Discussion about future of frontend technologies #8550, about the CO2 footprint, this could be a bit more efficient: using the JIT mode (default in the new v3) the system only includes the definition for the classes you are using
7. It's officially integrated with Rails 7, and it matches with all the changes being made in the asset pipeline
8. It has very good documentation and resources
9. As it's getting lots of traction, it's expected that more developers will be more familiar with Tailwind than with Foundation.

Arguments against changing (to Tailwind or any other)

The main argument for not changing CSS framework is backwards compatibility. Changing the CSS framework means rewriting lots of HTML to make use of new classes. We see two areas regarding this:

"Default" redesign

Given that so many things are going to change, the cost of starting from scratch will be lower than reusing the current markup. This difference might be significant, since some elements that now share markup are going to have a different design (i.e., cards of different components that now share code, in the future won't, probably). We would take this opportunity to streamline and modernize the markup where needed.

In conclusion: keeping the current markup to guarantee backwards compatibility imposes a cost, with few or no advantages (actually the contrary, since using Tailwind gives us many). Also, the new design brings new elements or substantial changes in key elements (navigation, proposals...), so even if we maintain some current classes, many will be new.

Already customized sites with lots of changes

If you have a Decidim with no HTML customization, the upgrade will be seamless. If, on the other hand, you have customized your HTML, you'll be forced to rewrite your HTML to upgrade. This will impose a cost to those installations which might be significant.

But, given the changes that the redesign is going to bring, highly-modified installations will have whatsoever a cost to upgrade their designs to the new design even if we maintain some classes.

Our conclusion

In our view, given the advantages we anticipate for the change, and the fact that highly-modified installations will have to invest to adapt to the upgrade in any case, we consider the change to Tailwind as the best option that will improve developer experience and ease of customization.

[ahukkanen]

I am against Tailwind.

I am not against changing the underlying CSS framework.

While I understand the popularity of Tailwind, I am a strong supporter of the standards and to me Tailwind is trying to eliminate writing CSS, getting rid of one part that controls how things look and instead dictate it in the markup.

The HTML becomes cluttered with different classes and each representation of the same element can look different depending on the classes that were added there and has to be maintained over all the modules and apps that implement the same elements. To me it sounds similar what we did in the "ancient times" with <table> layouts (what we still use in HTML emails).

I would much rather see a standardized approach to the UI where e.g. a .card class would always create a standard looking card without adding any extra classes to it. And CSS would control what it looks like.

The webpacker migration has made a bad impression that CSS is bad. It doesn't have to be that way.

[froger]

My 2cents here,
I see here comparaisons of things that are quiet different from my perspective.
Models manage well database records and data integrity. Controller validates user's input. Theses are two completely separated contexts.

HTML/CSS are on the same context in my head. I start first for accessibility to markup (HTML markup is the style for a lot of people). And then I decorate with CSS. These are two separate techs, but they work within the same context: views.

@ahukkanen could you explain to me why CSS should not be mixed with the markup of the page? Looks like it is obvious to you and it is not so much to me :)

Thanks

[ahukkanen]

@froger HTML and CSS serve a different purpose. E.g. on the W3C page it is stated:

HTML (the Hypertext Markup Language) and CSS (Cascading Style Sheets) are two of the core technologies for building Web pages. HTML provides the structure of the page, CSS the (visual and aural) layout, for a variety of devices.

https://www.w3.org/standards/webdesign/htmlcss

I understand you see it differently. You don't see a conflict mixing near style-tag specific styling with the markup. It is still "CSS" even if we write it in the style tags directly.

For me HTML is for structure and CSS is for styling.

If I try to put my perspective really simply: why we don't write inline styles in Markdown? The same reason why I think we shouldn't write inline styles (or very close to that) in HTML.

[furilo]

@ahukkanen have you actually used Tailwind in a real project? (the example code you provided makes me doubt). I had similar concerns before doing it, but now that we have used it we have changed our minds.

[ahukkanen]

@furilo No I have not used because I don't like the idea. But I have investigated it before and thought I wouldn't use it.

I think Tailwind would not provide standard holistic approach for the UI, because you have to specifically define how each element looks like in the HTML. Then if you have that same element in some other view/context/module/app, you have to add exactly the same classes to that and keep that up-to-date when the core element is changed.

This does not sound very standardized to me.

[ahukkanen]

@furilo I just wanted to add here that I am not against the CSS-standardization aspect of Tailwind, I am just against applying the Tailwind classes to the views directly.

If you extract the Tailwind classes away from the HTML markup and specify a CSS layer above it (which Tailwind also supports), then I would be OK with it.

[froger]

Thanks for sharing @andreslucena !
Before debating against Tailwind, I would like to describe what I would expect from this change:

1. I should be able to theme decidim, meaning changing colors, radius, spacing, fonts families and fonts scales.
2. I should be able to "specialize" a unique component without crazy border-effects everywhere.
3. It should have a coherent API (meaning a consistent naming <-> behaviour).

To me Tailwind can be great, if we define some clear boundaries. No objections my side to go with it.
I am just particularly concerned about rules and boundaries: Your example from-cyan-500 to-blue-500 would be a true hell to customise: I should change the html markup or set a crazy from-cyan-500 {background: red}.

Coming from React, I consider HTML+CSS as a unique concern: displaying things. As decidim has a lots of "things", standardized "<choose your lib>" is a must, I think.

[ahukkanen]

@Crashillo We've went through a similar route back in 2018 when Helsinki wanted to migrate their UI to the Helsinki UI library back then. We needed to touch every single view they used in Decidim. A complete maintenance nightmare.

Since then, we decided to just accommodate their layout to the framework Decidim provides. Works much better and is much more maintainable.

Since then, Helsinki has also abandoned their own UI library and instead they are maintaining a design system where different applications can adapt what they need. Such as Decidim.

I would much rather maintain 40'ish CSS files that customize the styles than forking 1500 views/partials/cells/components to change how it looks like. And update those after every Decidim update. Way easier to maintain.

[Crashillo]

Overriding is a feature Decidim allows. A nice-to-have, in case you wanna change something. Something, not the whole app. For that purpose, overriding is not an option, better use the API and implement your own front-end.

[ahukkanen]

Overriding is a feature Decidim allows. A nice-to-have, in case you wanna change something. Something, not the whole app. For that purpose, overriding is not an option, better use the API and implement your own front-end.

@Crashillo Isn't that a conflict between what you said above?

If your customization goes beyond that a simple theming, you should be able to update a full component on your own, in a very similar way to override a view. In that scenario, using Tailwind, you could style your overrides with no more setup than your view.

So, if I'm reading this right you want to:

1. Make customization possible at the component view layer, not having to touch any CSS to do that
2. Not suggest doing that... (use API instead?) - [sidenote: the API is years away from being complete enough to be able to do that]

Also, if you really take it that far that you can customize anything in Decidim at a component level, we need to have components for e.g. "button", "link", "heading", "paragraph", etc. I'm still not convinced you are trying to do the right thing in the right framework.

This might be a bit more understandable if you were writing a React application. In Rails context I don't understand why you'd try to achieve this.

[Crashillo]

Isn't that a conflict between what you said above?

No, since in both cases I'm referring to change a few things. A normal customization will apply to the colors, fonts... something easy to drive from the admin via CSS vars.

Now let's say you wanna go further: change the footer or a card design. If we're suggesting move from Cells to ViewComponents you can create a component Card, or Footer (there's no need to do so many atomic components). Then you'll replace the default card component with one on your own. But one, two... five overrides at most.

I mean, the way would be to get a functional API in order to change the front as much as you want; not about overriding tons of views to achieve it. Since the first won't be done shortly, the current customization options plus some views should be enough.

[ahukkanen]

If we're suggesting move from Cells to ViewComponents you can create a component Card, or Footer (there's no need to do so many atomic components). Then you'll replace the default card component with one on your own. But one, two... five overrides at most.

I think you are underestimating the effort that really goes this in real life cases where we have to do customizations.

Currently we already have cells (which we can say is a synonym to ViewComponents in this discussion) for the cards, but the classes and markup is still scattered in each specific card implementation. For example, to change the proposal card, you would have to customize the parent card component as well as the proposal card component which contains its own markup and classes. So OK, you go through that and you just overrode the main card (11 views + 1 component class) and the proposal card (2 views + 1 component class). Now, repeat this for debates, meetings, budgets, results (accountability), sortitions, etc. All that just to change how the card looks like...

If the "atomic" components are implemented as they are right now in Decidim, which I think will be the end result from this, this will be the same maintenance nightmare that we have already gone through once.

But if you were to create UI components which are completely unaware of their context (e.g. is it a proposal or debate card), it might make more sense. So instead of showing a "proposal card", you would just show a "card" with specific configurations which don't contain any markup. If all the possible markup we can have in any "card" would be wrapped in the "card" component itself, it would be much easier to maintain. There would have to be really clear separation of the UI component from any external logic that the UI component does not have to be aware of. And that alone is a huge task.

But even if that's done, I still think it's a bad idea in Rails context to go that far as defining components for "button", "link", "heading", "paragraph", etc. what you would eventually need with Tailwind.