Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I disagree. I find that SASS mixins provide the same reusability as classes but in a much cleaner way. True, it makes your HTML and CSS very coupled, but it does provide you with a true clean separation of content and presentation.

I find

  // style.scss
  @mixin button($color, $size) { ... }

  .download-book {
    @include button(
      $color: red,
      $size: big
    );
  }

  .send-email {
    @include button(
      $color: blue,
      $size: small
    );
  }

  // index.html
  <button class="download-book">Download book</button>
  <button class="send-email">Send email</button>
much cleaner than

  // style.scss
  .button { ... }
  .red { ... }
  .blue { ... }
  .big { ... }
  .small { ... }

  // index.html
  <button class="button big red">Download book</button>
  <button class="button small blue">Send email</button>
1. When you change the visual aspect of an element, you go to the stylesheet and don't go adding/removing classes from the content layer (HTML).

2. When using generic names like "button", "big", "small", etc... I always find myself in a naming conflict at some point. The likelihood of semantic names having conflicts is much smaller.

Of course, your CSS file becomes a lot bigger. But when enabling compression, the stylesheets using mixins turn out to be smaller (see https://tech.bellycard.com/blog/sass-mixins-vs-extends-the-d...). Also, your HTML file is likely smaller too when using semantic classes.



A class called "download-book" wouldn't be semantic either.

A semantic choice of classes should represent the roles that things have in the UI hierarchy: if a "book download" button is the main action of the page, it should have a class of, say "main-action", possibly with an extra "download" class to show UI specific to download actions.

If a "book download" button is just an action, for example a button that is repeated multiple times in a table, then it needs a different class, like "action", still possibly with "download".

This is exactly like properly written HTML is semantic, elements represent hierarchical roles ("nav", "footer"), not their look, nor their content.


I find tha the library-style "button" "red" "blue" "big" example prevents me from having to flip over and maintain CSS with every HTML change.

Yet your first example has everyone editing CSS files and appending new classes to it all the time, which in my experience is the fastest way to end up with unmaintainable CSS.

Mixins sounded good to me at first, but I've only experienced less maintainability when the CSS was too clever.


> 2. When using generic names like "button", "big", "small", etc... I always find myself in a naming conflict at some point. The likelihood of semantic names having conflicts is much smaller.

css-modules[0] are a nice solution to this. Your nice, simple class names like "button" are transformed as part of build process to something less likely to collide, like "ltuZCYvCyDVU_2kG0Sspr":

[0]: https://github.com/css-modules/css-modules


I agree with your point of view as well. With Vue, I am writing all my styles in a .vue file which contains a component composed of style, markup, and js. It's incredibly clean and easy to maintain.

>> Of course, your CSS file becomes a lot bigger.

If you use something like webpack and you start splitting code based on the page you are on, this problem goes away as well.

I find that only place the 2nd case makes sense is if you are writing a CSS framework like Bootstrap. Otherwise, I find this way writing CSS increasingly rare.


that misses the point.

parent described things like moving the navbar to the left when the html can have it before or after the content on the dom. can you use float:left?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: