Tailwind removes ul/li tag styles - Open Discussion about CSS scope

[krowvin]

I started to update the landing page of CDA to use groundwork and I noticed when I went to add <ul> / <li> tags that groundwork resets these and removes their styles.

I understand why Tailwind might want to reset states of various components for their own styles, but should we expect users to know that some / all tags might be required to have components?

• If so how do we cover all of these cases?

Should users be able to use other CSS frameworks? Vanilla CSS still works

• Boostrap
• Foundation
• Materialize
• etc If the answer is yes, then we would need to determine how to embed the stylesheets in only the lower level (groundwork components). I have not tried this.

When I imported bootstrap that it added styles to the header (underline)

[adamscarberry]

Throwing in my 2 cents....

Using another CSS framework/library with Tailwind either will not work or will be a battle.

Groundwork does impose the rules of Tailwind which includes resetting styles on certain tags. This reset bugs me too on things like heading elements, but I get why they do it.

I think the two options for users are:

1. write your own style sheets and include in the index.css or
2. utilize/learn Tailwind (which means install/configure tailwind in your project)

I personally would not want to use a list item component because I would like more flexibility. It's pretty easy to use: <ul className='list-inside list-disc'>, but I get the jarring experience of "hey where's my list bullets?".

I know it may sound heavy handed to say drop existing css frameworks/libraries and use only Tailwind, but maybe if the site you are working on can't be re-built from scratch, you might not want to utilize Groundwork.

The advantage of setting Tailwind as the "preferred" CSS framework is the community can support one another and standardize.

[willbreitkreutz]

I tend to agree with Adam. Typically when using a full component framework you wouldn't use another css framework on top. i.e. if you were to use material-ui or mantine components you would use the utility classes they provide to do any custom stuff.

Tailwind is a little bit of a double-edged sword, the tree-shaking done at build time ensures that your shipped css is relatively clean, only including the classes you need, however you lose the ability to use any of the tailwind classes in a consuming app unless they are classes we used in groundwork. I name-spaced the groundwork css so that using another layer of tailwind on top doesn't conflict, but it doesn't mask out the opinionated reset that tailwind does.

[krowvin]

will not work or will be a battle.

And it would add bloat / larger files to deal with. Bit redundant too, I didn't mean to suggest two full css frameworks. Maybe with the tree shaking Will mentions that doesn't really matter as much. But using bootstrap vs tailwind there are for sure some duplicate classes there for similar things.

however you lose the ability to use any of the tailwind classes in a consuming app unless they are classes we used in groundwork.

Well that actually explains some of the issues I was running into trying to use tailwind. I'll make sure to install/import it properly in my project too then. And you probably said this before but now I've experienced it and that's 💯

jarring experience

I think we should have a page, or possibly on the get started stating some of the gotchas to this. Things like:

• Tailwind does resets on many base level tags for cross browser support see Preflight for details
• It is NOT recommended to use multiple CSS frameworks due to CSS overwriting each other / naming conflicts. Do this at your own risk. Groundwork™ expects you to be using Vanilla CSS or Tailwind for all your styling needs.