테일윈드 유틸리티에서 벗어나 순수 CSS 구조화 배우기

Hello! 8 years ago, I wrote excitedly about discovering Tailwind . At that time I really had no idea how to structure my CSS code and given the choice between a pile of complete chaos and Tailwind, I was really happy to choose Tailwind. It helped me make a lot of tiny sites! I spent the last week or so migrating a couple of sites away from Tailwind and towards more semantic HTML + vanilla CSS, and it was SO fun and SO interesting, so here are some things I learned! As usual I&rsquo;m not a full-time frontend developer and so all of my CSS learning has happened in fits and starts over many years. it turns out Tailwind taught me a lot When I started thinking about structuring CSS, I was intimidated at first: I&rsquo;m not very good at structuring my CSS! But then I started reading blog posts talking about how to structure CSS (like A whole cascade of layers or How I write CSS in 2024 ) and I realized a couple of things: Every CSS code base has a bunch of different things going on (layouts! fonts! colours! common components!) It&rsquo;s extremely useful to have systems or guidelines to manage each of those things, otherwise things descend into chaos Tailwind has systems for some of these, and I already know those systems! Maybe I can imitate the systems I like! For example, Tailwind has: a reset stylesheet a colour palette a font scale the systems I&rsquo;m going to talk about I&rsquo;m going to talk about a few aspects of my CSS codebase and my thoughts so far what kind of rules I want to impose on the codebase for each one. Some of them are copied from Tailwind and some aren&rsquo;t. reset components colours font sizes utility classes the base spacing responsive design the build system 1. reset I just copied Tailwind&rsquo;s &ldquo; preflight styles &rdquo; by going into tailwind.css and copying the first 200 lines or so. I noticed that I&rsquo;ve developed a relationship with Tailwind&rsquo;s CSS reset over time, for example Tailwind sets box-sizing: border-box on every element (which means that an element&rsquo;s width includes its padding): * { box-sizing: border-box; } I think it would be a real adjustment for me to switch to writing CSS without these, and I&rsquo;m sure there are lots of other things in the Tailwind reset (like html {line-height: 1.5;} ) that I&rsquo;m subconsciously used to and don&rsquo;t even realize are there. 2. components This next part is the bulk of the CSS! The idea here is to organize CSS by &ldquo;components&rdquo;, in a way that&rsquo;s spiritually related to Vue or React components. (though there might not actually be any Javascript at all in the site) Basically the idea is that: Each &ldquo;component&rdquo; has a unique class The CSS for one component never overrides the CSS for any other component Each component has its own CSS file So editing the CSS for one component won&rsquo;t mysteriously break something in another component. And probably like 80% of the CSS that I would actually want to change is in various component files, so if I&rsquo;m editing a 100-line component, I just have to think about those 100 lines. It&rsquo;s way easier for me to think about. For example, this HTML might be the .zine &ldquo;component&rdquo;. <figure class="zine horizontal"> <img src="whatever.jpg"> </figure> And the CSS looks something like this, using nested selectors: .zine { ... &.horizontal { ... } &.vertical { ... } &:hover { ... } } I haven&rsquo;t done anything programmatic (like web components or @scope ) that ensures that components won&rsquo;t interfere with each other, but just having a convention and trying my best already feels like a big improvement. Next: conventions to maintain some consistency across the site and keep these components in line with each other! 3. colours colours.css has a bunch of variables like this which I can use as necessary. Colour is really hard and I didn&rsquo;t want to revisit my use of colour in this refactor, so I left this alone. The only guideline I&rsquo;m trying to enforce here is that all colours used in the site are listed in this file. :root { --pink: #fea0c2; --pink-light: #F9B9B9; --red: #f91a55; --orange: rgb(222, 117, 31); ... } 4. font sizes One thing I appreciated about Tailwind was that if I wanted to set a font size, I could just think &ldquo;hm, I want the text to be big&rdquo;, write text-lg , and be done with it! And maybe if it&rsquo;s not big enough I&rsquo;d use xl or 2xl instead. No trying to remember whether I&rsquo;m using em or px or rem . So I defined a bunch of variables, taken from Tailwind, like this: --size-xs: 0.75rem; --line-height-xs: 1rem; --size-sm: 0.875rem; --line-height-sm: 1.25rem; Then if I want to set a font size, I can do it like this. It&rsquo;s a little more verbose than Tailwind but I&rsquo;m happy with it for now. h3 { font-size: var(--size-lg); line-height: var(--line-height-lg); } 5. utilities There are some things like buttons that appear in many different components. I&rsquo;m calling these &ldquo;utilities&rdquo;. I copied some utility classes from Tailwind (like .sr-only for things that should only appear for screenreader users). This section is pretty small and I try to be careful about making changes here. 6. the base &ldquo;base&rdquo; styles are styles that apply across the whole site that I chose myself. I have to keep this section really small because I&rsquo;m not confident enough to enforce a lot of styles across the whole site. These are the only two I feel okay about right now, and I might change the <section> one: /* put a 950px column in the middle of each <section> */ section { --inner-width: 950px; padding: 3rem max(1rem, (100% - var(--inner-width))/2); } a { color: var(--orange); } I think for the base styles it&rsquo;s going to be easiest for me to work kind of bottom up &ndash; first start with almost nothing in the base styles, and then move some styles from the components into base styles as I identify common things I want. 7. spacing I haven&rsquo;t completely worked out an approach to managing padding and margins yet. I&rsquo;m definitely trying to be more principled than how I was doing it in Tailwind though, where I would just haphazardly put padding and margins everywhere until it looked the way I wanted. Right now I&rsquo;m working towards making the outer layout components in charge of spacing as much as possible. For example if I have a <section> with a bunch of children that I want to have space between them, I might use this to space the children evenly: section > *+* { margin-top: 1rem; } Some inspiration blog posts: the owl selector &ldquo;no outer margin&rdquo; 8. responsive design: use more grid! The way I was doing responsive design in Tailwind was to use a lot of media queries. Tailwind has this md:text-xl syntax that means &ldquo;apply the text-xl style at sizes md or larger&rdquo;. I&rsquo;m trying something pretty different now, which is to make more flexible CSS grid layouts that don&rsquo;t need as many breakpoints. This is hard but it&rsquo;s really interesting to learn about what&rsquo;s possible with grid, and it&rsquo;s a good example of something that I don&rsquo;t think is possible with Tailwind. For example, I&rsquo;ve been learning about how to use auto-fit to automatically use 2 columns on a big screen and 1 column on a small screen like this: display: grid; grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content)); justify-content: center; I also used grid-template-areas a lot which is an amazing feature that I don&rsquo;t think you can use with Tailwind. Some inspiration: A responsive grid layout with no media queries from CSS Tricks 9. the build system: esbuild In development, I don&rsquo;t need a build system: CSS now has both built in import statements, like this: @import "reset.css"; @import "typography.css"; @import "colors.css"; and built in nested selectors, like this: .page { h2 { ...} } If I want, I can use esbuild to bundle the CSS file for production.