CSS Utility Classes and “Separation of Concerns” (2017)
1–10 of 108 posts
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#2I never liked to do CSS, but I must admit with the library this guy released (tailwindcss), it's really fun :)
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#3The money quote for me:
"The reason I call the approach I take to CSS utility-first is because I try to build everything I can out of utilities, and only extract repeating patterns as they emerge."
I've been puzzling over the same "Separation of Concerns vs. Mixing Concerns" dichotomy ever since the rise of Bootstrap. Something about using Bootstrap's classes never felt right to me, but I was never happy with the amount of duplication in my traditional CSS either... I eventually settled on BEM, but that didn't 100% solve the issues either, and it seems to be getting left behind as the ecosystem gets older.
The idea of starting with the Bootstrap-like functional CSS, and then compositing repeated patterns into components, definitely seems to have tremendous upsides... Looking forward to trying this methodology out in a future project.
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#4For me, CSS has been a Solved Problem™ for 5 years now.
If a website is small then I write plain HTML/CSS/JS in the old school way and all of these abstractions/systems are YAGNI.
If a website is large enough for these abstractions to matter then I'm using React with inline CSS. I get reusability and composition without a noticeable performance tradeoff. You can still build your components to decouple style from content where needed. Up to you.
Years later, no issues.
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#5I think utility classes _first_, and not utility classes _only_, is a reasonable approach. My purist mind would prefer something like semantic classes as a sort of 'public', 'HTML-facing' API, implemented using 'private' utility mixins, keeping the separation of concerns. But in practice, I know I have wasted a lot of time thinking about class hierarcies and separating components, especially when the design is nowhere finalized and I just want a 4px padding.
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#6The real issue with css is that there is an enormous amount of code re-use while at the same time almost no code-reuse at all. The author's example highlights this perfectly: he has a "media-card" representing both the "author-bio" and "article-preview" but the "author-bio", in this case, needs to be slightly different. This, to me, is the quintessential css problem.
Almost nothing in css is identical, but almost everything is similar.
This becomes especially true as you move up the complexity spectrum. Primitive things can be identical (fonts, colors, input boxes, etc.), but the real higher-order actual components like pages, forms, sections rarely are. In fact, the little differences, tweaks and custom-tailoring that are manually applied based on context are what separate professional design from robotic enterprise-style Frankenstein design.
I think the answer is that you need both semantic css and utility css. Utility css is used to define the rigid primitives that make up the general design language, while semantic css provides the hooks and separation needed to be able to uniquely compose those primitives into custom higher-order components.
So to answer the author's question regarding how to model "author-bio" and "article-preview", I would personally keep their separate semantic titles, but style them using common utility primitives classes and custom css within the css.
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#7You can have many classes. So in your markup you can have an item that is both class article and class bio. Then on another page that is the same but different the class can be article preview.
Then in the CSS you make rules for .article and where bio and preview differs you use .article.bio or .article.preview respectively.
In CSS specific rules overrides general rules. So .article.bio would inherit all .article rules and also override.
I like to start out my style sheet (CSS) by only using the semantic HTML elements like h1, button, etc. Then when the design advances and I go down to the small details - I add more and more specific rules.
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#8From my experience, using utility classes like this just means that you'll have a lot of messy overriding to do when your reusable components need to look different in different places.
Personally I think visual consistency is important and you shouldn't make things look different in different places, but it's not always up to me.
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#9I've been writing sites like this for years.
It can look sloppy, but I find that it's important to provide as many "hooks" as possible to elements; especially dynamically-generated elements.
This is because I've written tools that were meant to be integrated into sites, as opposed to the end site, itself.
It was important that the user of the tool be able to exert as much control as possible over the rendering.
It does look messy as hell, though. Inspect Element is very helpful. Since a lot of the dynamic code is optimized anyway, or rendered by AJAX, display page source is kinda worthless.
It's all about keeping the specificity as weak as possible, while allowing the CSS to focus on individual elements, or collections of elements.
Re: CSS Utility Classes and “Separation of Concerns” (2017)
#10The real issue with css is that there is an enormous amount of code re-use while at the same time almost no code-reuse at all. The author's example highlights this perfectly: he has a "media-card" representing both the "author-bio" and "article-preview" but the "author-bio", in this case, needs to be slightly different. This, to me, is the quintessential css problem. Almost nothing in css is identical, but almost eve…
In programming, this problem would be solved with something like higher order functions or parametric data types, allowing us to both abstract out the commonalities and maintain incredibly specific, easily modifiable, highly customized functionality. Is there an analog in the CSS world?