5 ms·

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

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.

jonahx 10y ago
> 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.
- phailhaus 10y ago
  > That's because it shouldn't be. 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).
  - jonahx 10y ago
    > 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.
    - phailhaus 10y ago
      > 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.
      - jonahx 10y ago
        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.
        phailhaus 10y ago
        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.

jonahx 10y ago

> 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.

phailhaus 10y ago
> That's because it shouldn't be. 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).
- jonahx 10y ago
  > 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.
  - phailhaus 10y ago
    > 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.
    - jonahx 10y ago
      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.
      - phailhaus 10y ago
        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.