DEV Community

Discussion on: Why I switched from normal CSS to Tailwind CSS

Collapse
 
uuykay profile image
William Kuang

Yes size gets moved to HTML, however, it is a fair tradeoff. Every HTML page that needs those styles, has them. The CSS then gets treated as a common import - with a finite size. The problem with other approaches is that there are often bad / changing categorisations of things when building. This results in duplication of CSS which is not easy to untangle.

Collapse
 
sebbdk profile image
Sebastian Vargr

What are you thoughts on CSS duplication being mostly removed with proper compression?
I'm also not sure what you mean by bad/changing categorizations, could you give an example?

Thanks! :)

Thread Thread
 
uuykay profile image
William Kuang

The categorisation problem is the adage that naming things is hard. I have worked with designers and PM's who start with one design, and then cascade to many many variants without telling you in advance.

For example, say there is a component that only exists on the settings page - like a block of text above a group of buttons. You might start by calling the CSS container .settings-page as the block. Then you might call the text the .settings-page_text as block and element, then you might call the button group .settings-pagebutton-group, then you might call the individual buttons as .settings-page_button--primary to have block, element, and modifier.

Then your designer/PM likes the button group and wants to use it in a completely different page. You can no longer use the previous naming convention. This example is a bit contrived, but what I am pointing out, is that you can't always know in advance, how the naming should actually be for your usage. What you can know is that a button should be say primary and you apply the atomic style to style it primary.