Tailwind or cube css discussion

[amazingphilippe]

This is a discussion concerning what we should consider moving forward with the CDS website in terms of css/sass/styles.

What we have now: some WET css theme with some sass. There are 2 css files loaded overall.

I'm going to make the case for CUBE CSS, but I invite Tailwind advocates to make a case for it too, I've been less enthusiastic about it, I don't want it to show in this first comment.

Cube is only a methodology. It's not a library or a pre-compiled style sheet. It has no base theme, it has no opinions about the tech we use. The most important principle when writing CUBE is to keep it simple, and make use of the cascade instead of re-introducing inherited properties.

CUBE is

• composition
• utility
• block
• exception

Utilities are exactly like tailwind. They are classes that set one property like color and display, or set spacing between child elements. The utilities always do only one thing. We could even consider naming our utilities like tailwind, or even import the entirety of tailwind as our utilities into our CUBE CSS methodology. The one cool thing about not using tailwind is that we get to set our own design tokens (colors, spacing, fonts...).

Blocks are more complex common components. I believe if we had a nice tailwind build process, we could use their @apply rules, or we could use partials to create our components.

Compositions are flexible arrangements that should be able to be dropped anywhere and adapt to the available space on the webpage. Usually, these, rely on a few lines of code containing layout directives that shouldn't break depending on the available space.

Like this composition for a signup form:

.sign-up {
  &__form {
    flex-basis: 20rem;

    input,
    button {
      width: 100%;
    }
  }
}

The form part has a basis of 20rem, and it's input and button should fill the available space. We can understand how this composition will adapt itself to its allocated space, and leave the markup free of specific sizing attributes that don't strictly relate to them. Lame example: copying the button from that form elsewhere, it would lose it's 100% width, which makes sense because not all buttons should be 100% wide.

Exceptions: these are like BEM exceptions. However, they are not defined in the class name, but rather in a data-attribute. This makes it easy to hook js into our components, and is less messy in scss. (think of those &--foo { ... } exceptions) There are some added benefits to using data attributes too, since they're more easy to target, toggle or modify using JS. instead of removing and adding classes.

but y

I'm not saying we should, but I think it would be enjoyable. Seeing we have a lot of new designs for the website, working with the current styles might cause some pain. Especially when it comes to breakpoints, duplicated styles, inheritance from WET.

Tailwind and cube aren't incompatible with each other.

1. We could inspire ourselves from tailwind css and have a great cube css library
2. We could inspire ourselves from cube principles and build a sweet tailwind scss build process

[dj2]

See PR #2144 for an example of the CUBE system.

[dj2]

Do we have an idea of how much pain the current styles are causing? Is it primarily due to the organic growth of the website? The strange combination of WET and home grown CSS?

For CUBE, is there a build step that runs, or is it just a system for writing the components down, but the components themselves are SASS?

In your example above, does &__form get rewritten into a form somewhere so it matches all forms under .sign_up or does it mean something different?

[amazingphilippe]

Do we have an idea of how much pain the current styles are causing? Is it primarily due to the organic growth of the website? The strange combination of WET and home grown CSS?

I think that's a valid question to be answered by everyone that wants to be part of this. I tried reworking the header once to make it play nicer with media queries. I abandoned because it led me to too many changes in too many places and I had to resort to writing even more custom css overrides.

For CUBE, is there a build step that runs, or is it just a system for writing the components down, but the components themselves are SASS?

No build step. Its all sass. The dependency added in the example PR is all sass powered, we can choose to use it or not, it basically generates the utility classes based on sass maps.

In your example above, does &__form get rewritten into a form somewhere so it matches all forms under .sign_up or does it mean something different?

not in this example, but your idea is exactly in the spirit of CUBE! we could choose to target any form instead of specifically the one classed with sign-up__form

this is what my example would output:

.sign-up { ... }
.signup__form { ... }

your suggestion would look more like this?

.sign-up {
  form { ... }
}

which would output

.sign-up { ... }
.sign-up form { ... }

[dj2]

Reading over the PR and comments above I think I have a better understanding of what's happening in the PR. So, if I'm understanding correctly:

1- CUBE is, essentially, breaking your SASS into small contained chunks instead of a single large SASS file? That seems like a good idea to me.

2- Is Gorko, which is generating some files based off an input json file. I think we should hold off on that for now, split it out to a separate PR and we can decide if we want to use it or not.

3- Is the question of tailwind vs something else. As @amazingphilippe says, Tailwind and CUBE are complementary. To me the right approach is to use Tailwind when we can, and when we have to build ourselves, use the CUBE structure where we build small components that we bundle together.

4- I think for the initial PR we should just create the minimal set of changes needed to support the footer. Leave the WET-BOEW import in the HTML, and only have enough changes, in the CUBE style, to support the new footer design. This would show us what the layout looks like on a much smaller scale.

5- At some point, we should probably look at integrating Tailwind into the main site and start simplifying our stying down where possible, but that should be filed as a followup issue if that's the direction we decide to take.

[amazingphilippe]

1. 👍
2. I think that's the idea, but reading your point made me doubt myself. I think we don't even use json. I may have forgotten to remove this comment from another project. Gorko only contains scss. It generates handy sass functions and mixins. It also generates utility classes based on our tokens scss file. If we would remove this we would lose those tools.
3. I think that's the right approach: utility classes most of the time, CUBE for composing css components. If we had a full-blown tailwind build process, we could use their @apply thingy to compose components.
4. Sounds good. Note that this PR contains a lot of problems, especially with the layout. I think I'd like to fix some stuff before we consider it for merging.
5. Like number 4, the main headache with combining WET with CUBE with Tailwind will be to match layout sizes all across. (responsive container widths, gap/column spacing, padding and margin, type sizes...) Maybe we need to map out which library can take care of what, but that also makes it harder to eventually consolidate our css libraries. Another option would be to take the time to configure CUBE and tailwind to follow WET.

Another thing that bugs me with tailwind is not having access to our own design tokens like fonts and colours. If I use tailwind's color-blue, I get this blue colour that doesn't fit in nicely with WET. I don't know if tailwind's yellow would match the CDS yellow. I think there are a lot of unresolved compromises to make if we choose to use tailwind, but there may be solutions to these problems that I am unaware of.

[dj2]

I haven't really used Tailwind, but would this be a place where if we figured out a Theme (https://tailwindcss.com/docs/theme) for Tailwind that matched WET-BOEW we'd be able to re-use it over multiple projects?

[brdunfield]

Yes, you can extend or fully replace tailwind defaults very easily!

[amazingphilippe]

Should we close this seeing how we're well underway building the new pages without changing the current project structure? Or is it still something we'd like to look into in the future? I'm thinking there might be little interest in changing how pages are built.

[dj2]

I'm guessing this might be too large to do anything about at the moment. Maybe if there were small changes we could put up in PRs to start breaking things apart and making them more composed would be a better way forward?

So, I'd vote for closing.

[amazingphilippe]

Just closing this issue because it doesn't align with how we want to do things right now. Feel free to reopen if you (yes, you) think this was a good idea and you know of a way we could have a better developer experience and less repeated, leaner CSS.