Grow your CSS skills. Land your dream job.

Semantics, OOCSS and DRY.

  • # July 1, 2013 at 3:24 pm

    Hi, I started to read about OOCSS, then about semantics in CSS class names and the whole thing about separating content from presentation.

    Reading this article http://css-tricks.com/semantic-class-names/ is helping a lot.

    So I understand that OOCSS could loose some semantics, like the way Bootstrap does with classes like ‘text-right’ or ‘pull-left’.

    Then there is the “media” object example, and how could be turned for a more semantic approach. Explained in this other article http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way-to-css/

    I´m using LESS instead of Sass, but i believe they both do the same way.

    so for example if there are this 2 kind of articles in the page:

    and they need to share the same CSS code:

    `background: #eee; color: #333; padding: 10px 20px`

    you could do this:

    and then the .mod class ( and OOCSS class , I supose) will have the ‘common’ code

    What you can achieve like before mentioned article does, is to save the .mod ( OO & presentational name class) this way with LESS

    #bundle {
    .mod () {

    background: #eee;
    color: #333;
    padding: 10px 20px;

    }
    }

    .movie-review,
    .breaking-news {
    #bundle > .mod;
    }

    which compiled in this CSS:

    .movie-review,
    .breaking-news {
    background: #eee;
    color: #333;
    padding: 10px 20px;
    }

    The question is: what about if you don´t want ( or you can´t ) to have grouped css declarations like those?

    e.g. this situation:

    .movie-review {
    #bundle > .mod;

    font-style: italic;
    }
    .breaking-news {
    #bundle > .mod;

    margin-bottom: 20px;
    }

    then the .mod part of code will be repeated twice in the final CSS, just for this example, what might be 100 times , or who knows how many times necessary, through all relevant code.

    Any thoughts on how this can be avoided? if it can be.

    # July 1, 2013 at 7:02 pm

    I found that the @extends Sass feature is one of two which LESS is not supporting Right now

    http://designshack.net/articles/css/extends-and-control-directives-two-crazy-things-sass-can-do-that-less-cant/

    # July 1, 2013 at 7:38 pm

    Finally I read tris article saying LESS beta 1.4
    Support @extends

    http://css-tricks.com/sass-vs-less/

    Excuse the rush

    # July 1, 2013 at 9:08 pm

    You wouldn’t want to target these like this:

    .movie-review,
    .breaking-news {
    background: #eee;
    color: #333;
    padding: 10px 20px;
    }

    It’s to specific. Instead, make the article your component: http://codepen.io/anon/pen/KAGvL

    So something like:

    .article{ /* default styles */}
    .article-news{ /* news modifier styles */}

    http://nicolasgallagher.com/about-html-semantics-front-end-architecture/

    # July 2, 2013 at 2:55 am

    I think the most important article you should read and understand related to this subject is the [Nicolas Gallagher article](http://nicolasgallagher.com/about-html-semantics-front-end-architecture/) @AlenAbdula just added at the bottom of his reply.

    # July 2, 2013 at 9:53 am

    Thanks both of you, I have seen the article , is one of the best.

    The codepen you provide Alen, that was the question oriented to.
    Because first I found [this article: Thoughts on semantic HTML class names and maintainability](http://www.brettjankord.com/2013/02/09/thoughts-on-semantic-html-class-names-and-maintainability/) which led me to this other one
    [“I believe presentational classes have a place, but it is not in our HTML”](http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way-to-css/)
    talking about simplifying and removing modular/presentational classes.

    I modified the codepen provided,
    http://codepen.io/anon/pen/ecqKC, I know is against your answer, but maybe could be acceptable?

    These days I`ve been reading about the debate, and I think that you can go modular or semantics, but must sacrifice something to focus on each other. And be a matter of choice, after all…

    # July 3, 2013 at 9:32 am

    maybe I worry too much about this topic but what about this paragraph in [this article (Roy Tomeij, thesassway.com)](http://thesassway.com/articles/sass-doesnt-create-bad-code-bad-coders-do “Sass doesn’t create bad code. Bad coders do.”)

    > “The extend directive creates a lot of ugly selectors”
    Ask yourself if your compiled CSS is meant to be human readable or machine readable. If you work in Sass, but know the resulting CSS will be hand edited, I would avoid extending selectors. When using @extend two times on a single selector, there will be code related to it at three places in the CSS (assuming you aren’t nesting extends).

    >For a browser however, the way the code is formatted doesn’t really matter, which is why minifying your code is a best practice. Pretty code is less important than performant code, and extending your selectors can definitely lead to DRY’er code than using mixins. On the other hand, don’t overdo it. If you find yourself extending your .clearfix class twenty times, you may consider adding it to your HTML (or learn how floats work). Use common sense.

    .article{ /* default styles */}
    .article-news{ /* news modifier styles */}

    this is the way Bootstrap organize classes, but considering all the above and the benefits of Sass, I think `. article` can be saved..

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

*May or may not contain any actual "CSS" or "Tricks".