内容简介:I've come across many articles and comments stating it's time to replace the framework's grid system with CSS Grid Layout. I can't entirely agree.A framework's gridis a "package" of utility classes that can be used in any project to distribute elements in
I've come across many articles and comments stating it's time to replace the framework's grid system with CSS Grid Layout. I can't entirely agree.
:zap:️ Design 10x faster with our library of 292 components →
Framework Grid vs CSS Grid
A framework's gridis a "package" of utility classes that can be used in any project to distribute elements in (responsive) columns and rows. It could include hundreds of lines of code or just a few rules. It could be that-framework-name 's grid or your custom grid system.
Here's an example fromCodyFrame's grid system:
<ul> <li/cdn-cgi/l/email-protection" data-cfemail="7e1d111253483e131a">[email protected]</a>"><!-- ... --></li> <li/cdn-cgi/l/email-protection" data-cfemail="284b4744051e68454c">[email protected]</a>"><!-- ... --></li> <li><!-- ... --></li> </ul>
CSS Grid Layoutis a subset of CSS properties used to distribute elements in (responsive) columns and rows.
For example:
.component-name { display: grid; grid-template-columns: repeat(3, 1fr); }
Any framework is an abstraction that uses CSS; it doesn't replace it. Consequently, we can't compare a framework's grid system with CSS Grid. The former could use the latter (i.e., a framework's grid system based on CSS Grid). The question "Which one is better?" doesn't make sense in this case .
However, we can discuss whether it makes sense to include a package of utility classes now that we have such powerful CSS layout properties.
Short answer: it may not if you're working on a small project. It does make sense the moment your project grows in complexity.
Enough with the theory! Let me show you an example. :point_down:
Starting a project using only CSS Grid
Let's imagine we're starting a project where, at some point, we need to create a grid.
.gallery { display: grid; grid-template-columns: repeat(3, 1fr); }
As we move forward with the project, chances are we need to create more grids:
.gallery, .form-grid, .list { display: grid; } .gallery { grid-template-columns: repeat(2, 1fr); } @media (min-width: 48rem) { .gallery { grid-template-columns: repeat(4, 1fr); } } .form-grid { grid-template-columns: minmax(100px, 250px) 1fr 1fr; grid-gap: 20px; } .list { grid-template-columns: repeat(auto-fit, minmax(180px, 1fr)); }
So far, so good! If our project was mostly done, why bother even thinking about importing a grid system? CSS Grid easily gets the job done.
The project grows in complexity
Imagine we need to apply the same grid to two components. What are we supposed to do?
Option 1)Use the same class.
<div> <!-- ... --> </div> <div> <!-- ... --> </div> <style> .form-grid { display: grid; grid-template-columns: minmax(100px, 250px) 1fr 1fr; grid-gap: 20px; } /* we decide to use the same class :point_up_2: */ /* .portfolio-gallery { display: grid; grid-template-columns: minmax(100px, 250px) 1fr 1fr; grid-gap: 20px; } */ </style>
This approach could go wrong for many reasons. First, a picky developer who loves semantics would dye inside a little. Most importantly, we would create an invisible connection between two components: changing the CSS of the first one would affect the second one. You're creating a trap for your future self.
Option 2)Create a new grid.
<div> <!-- ... --> </div> <div> <!-- ... --> </div> <style> .form-grid, .portfolio-gallery { display: grid; grid-template-columns: minmax(100px, 250px) 1fr 1fr; grid-gap: 20px; } </style>
Creating a new grid for the new component and grouping the classes would be the safest approach. Besides, it won't affect the CSS size.
Now imagine we get to the point where our project needs multiple (similar) grids. Should we keep creating a new grid for each component?
.gallery, .form-grid, .portfolio-gallery, .contact-gallery, .list { display: grid; } .gallery, .form-grid, .portfolio-gallery { gap: 20px; } .form-grid, .portfolio-gallery { grid-template-columns: repeat(3, 1fr); } .gallery { grid-template-columns: repeat(2, 1fr); } @media (min-width: 48rem) { .gallery { grid-template-columns: repeat(4, 1fr); } } .contact-gallery { gap: 16px; grid-template-columns: repeat(4, 1fr); } .list { gap: 40px; grid-template-columns: repeat(auto-fit, minmax(180px, 1fr)); }
Here are the weakest points of the above approach:
- Even though the grid classes are in the same SCSS file (highly unusual - typically, they'll end up in different SCSS/component files), and the number of grids is relatively small, dealing with the grid system is already getting more complicated.
- Each grid requires a different class name, and naming too many things can be frustrating.
- Because the classes are intertwined, modifying, or creating new grids requires a high concentration level. The risk of breaking things is high.
Sooner or later, we end up doing that only thing that makes sense: we create abstractions .
.grid { display: grid; } .grid-col-2 { grid-template-columns: repeat(2, 1fr); } .grid-col-3 { grid-template-columns: repeat(3, 1fr); } .grid-col-4 { grid-template-columns: repeat(4, 1fr); } .grid-auto { grid-template-columns: repeat(auto-fit, minmax(180px, 1fr)); } .gap-sm { gap: 16px; } .gap-md { gap: 20px; } .gap-lg { gap: 40px; }
Our grid utility classes are born out of necessity!
Here are the main advantages of abstracting grid utility classes:
- All the grid utility classes are in the same SCSS file and are easy to read.
- You can quickly expand the system if required by the project.
- No more naming things.
- If you use the same grid system across multiple projects, you won't need to inspect the CSS at all.
- Dealing with simpler CSS means reducing the risk of breaking things.
Conclusion
The main goal when working with CSS is maintainability: do what makes your code easier to maintain.
When working with grids, that means using utility classes if the project becomes more complex. It also implies creating the grids in HTML rather than in CSS. The "separation of concerns" is not the topic of this article. If you're interested, here's a video where I explain how we use utility classes at CodyHouse.
"Are you suggesting we should import a package of hundreds of CSS lines in every project just to manage the grid system?" No.
The framework's grid systems are usually massive because they include all the options, some of which you'll never use: responsive modifiers for all the breakpoints, offset, gap options, and so on. However, modern tools like PurgeCSS prevent your CSS from bloating and include in your CSS only the classes you actually use.
Are you looking for a great grid system? Check outCodyFrame.
Feedbacks/suggestions? Get in touch on Twitter . We'd love to hear what you think.
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
疯狂又脆弱 坚定又柔软
朱墨 / 湖南文艺出版社 / 2018-3 / 39.80元
《疯狂又脆弱 坚定又柔软》是朱墨的一部作品集,介绍了作者考研到北京,工作在华谊,以及留学去英国的经历,在这短短几年中她一路升职加薪,25岁升任华谊宣传总监,27岁赚到人生的第一笔100万,30岁却毅然离职去英国留学,在表面的光鲜亮丽之下,她也曾付出过外人所不知道的心血和努力。她的人生告诉我们,每一个身居高位或者肆意潇洒的人,都曾为梦想疯狂地倾尽全力,而那些心怀梦想的人也总是怀揣一颗坚定又柔软的内心......一起来看看 《疯狂又脆弱 坚定又柔软》 这本书的介绍吧!