You could look at "basket", "product", and "searchResults", except that it tells me absolutely nothing as a dev about what it looks like. You shouldn't be using your CSS classes to tag sections, that's what id is for. And now, if I want to change the "basket" style, I'm praying that I didn't break something on the other side of the application. So in order to mitigate that issue, you end up nesting your CSS for safety and now you've re-created your HTML structure with CSS rules and it's incredibly inflexible to changes. I've found that semantic CSS classes are a pipe dream that never pans out.
> except that it tells me absolutely nothing as a dev about what it looks like.
That's because it shouldn't be.
> You shouldn't be using your CSS classes to tag sections, that's what id is for
No, you might can have multiple "products" on the page.
> And now, if I want to change the "basket" style, I'm praying that I didn't break something on the other side of the application. So in order to mitigate that issue, you end up nesting your CSS for safety and now you've re-created your HTML structure with CSS rules and it's incredibly inflexible to changes. I've found that semantic CSS classes are a pipe dream that never pans out.
Absolutely none of this true if you use Sass (or an equivalent) properly.
Why not? Who's reading my HTML? It's not there to be read by a user. HTML is for devs. They're the ones that deal with it.
> No, you might can have multiple "products" on the page.
True, in that case you would use a CSS class with no styling if you need code to select the block.
> Absolutely none of this true if you use Sass (or an equivalent) properly.
It doesn't matter what you use, you can nest your CSS by hand or with Sass. Either way, you now have CSS tightly coupled to your HTML structure and it can be hell to change. I'm literally dealing with this right now (we use sass).
> HTML is for devs. They're the ones that deal with it.
Correct. You make it readable the same reason you make any code readable.
> It doesn't matter what you use, you can nest your CSS by hand or with Sass. Either way, you now have CSS tightly coupled to your HTML structure and it can be hell to change. I'm literally dealing with this right now (we use sass).
No. The whole point is if you use SASS properly you don't have to nest anything unless you want to.
> The whole point is if you use SASS properly you don't have to nest anything unless you want to.
I don't follow at all. One of the biggest selling points of Sass is being able to nest styles. If you don't need to nest styles, then Sass doesn't get you much. But once you start nesting, your CSS is coupled to your HTML. That's absurd.
it may be "a big selling point," but you're being sold a bill of goods.
using sass as you describe is an anti-pattern.
the important thing that sass allows you to do (which CSS should have built in, but doesn't) is to apply chunks of style to a named class. that is, precisely to decouple naming, styling, and html structure. you do this in sass with @extend or @include.
practically, this means i can take canned styles of my own making or from libraries like bootstrap, and then define my semantically named classes in terms of them. this allows composition at any level of granularity, total control over the units of re-use, and clear, readable markup.
I'm not convinced you can just call using a major feature of sass an "antipattern"... Without nesting, what you've described is essentially utility classes abstracted an extra level away under pretty names. Might as well get rid of that layer because it makes false promises. You'll end up reusing that CSS class and then find out that the usage in one area needs a slightly different markup. Cue nesting/extra CSS classes with slightly different names, etc.
There's this dream that you will need to "reskin" your application often, and be able to reuse a bunch of CSS classes all over your codebase. Instead what I've found is that it's better to think of your application as consisting of components with their own styling. Component-oriented frameworks like React are moving in this direction. Take a look at the styled-components library.
> It doesn't matter what you use, you can nest your CSS by hand or with Sass. Either way, you now have CSS tightly coupled to your HTML structure and it can be hell to change. I'm literally dealing with this right now (we use sass).
There is no way for you to mess up something at the other end of your web app if you use specific sass files for specific web pages. The 'basket' class can be defined as one thing on the page for selling baskets, and it can be defined completely differently on some other page where baskets are, idk, displayed in some other way.
Please elaborate. I don't see how having a library of SASS mixins that you mix in to make specific CSS classes for specific purposes make anything harder to manage? If anything, decomposing things to smallest common denominator makes it easier to build better and more versatile CSS for your apps.
It's not the sass mixins that makes things harder to manage. The problem is having nested CSS rules that cause your CSS to become tightly coupled to the structure of HTML. Then when the HTML changes, you have to rethink the relationships. And if you're not using nesting, then isn't what you described just utility classes abstracted one level away?
> HTML is for devs. They're the ones that deal with it.
As devs, we can view this html through a browser and use in-browser dev tools to view the associated CSS. There's no need to explain the style in the HTML.
You can still do that when you use utility classes. The benefit is that now you have a guarantee that you can drop a view anywhere in the application and have it render the same. I can restructure the HTML without worrying that I broke styling in an edge case.
