Live data from Hacker News

How We Could Write Better CSS

colmtuite.com

1–10 of 55 posts

Re: How We Could Write Better CSS

#3
I think there's a big need for an agreed upon standard for writing CSS. There's a lot of beginner stuff out there, but what sorely lacks is an idiomatic way to write proper CSS. You should write base styles and extend them, but to what extent? How should you group the properties? Heck, how should you structure the whole thing?

We need this. I've been thinking the same thing as the author for quite some time, I'm glad someone has at least put the idea out there.

Re: How We Could Write Better CSS

#4
Deeply nested CSS selectors in the source (like the ones in your MixPanel examples) are often a sign of CSS preprocessors in use. Using a tool like LESS or Stylus, MixPanel is probably including mixins in their styles that allow them the same modular flexibility you describe without cluttering the HTML with confusing, non-semantic classes like "mrm".

Edit: your site's visual design is awesome, btw

Re: How We Could Write Better CSS

#5
When you get to the level of abstraction demonstrated in the Facebook Margins example, you have so many classes for each element that you may as well go back to inline styles.

This also enables inconsistent UI in the front-end: some of my page-headers can have .mbl "Large bottom margins" and some could have .mbs "Small bottom margins".

Re: How We Could Write Better CSS

#6
while the mixpanel CSS is awful, the facebook CSS is not much better. any time you have to use a class that is descriptive of what the element should look like (for instance, .mas, which presumably stands for Margin All Small), you've tightly coupled the structure to the presentation and failed at CSS. While the article gets the idea mostly right, the counterexamples it uses are just as bad practice.

Re: How We Could Write Better CSS

#7
I'm a bit confused. I'm not a CSS expert by any means, but aren't h tags supposed to represent hierarchy, and by styling them differently in different places (apart from, say, colors or something) largely breaking the information hierarchy? It was my understanding that well-styled pages set up headings properly so that styling one heading different ways didn't need to happen.

Re: How We Could Write Better CSS

#8
While I agree with the general idea behind the article (object orient your css), I think the second demonstration involving margins is an example of OOCSS gone wrong.

If you are injecting your markup elements with classes like "mbm mts mrl" (or padding, or anything else that is essentially just a css property), this is not much different than just inlining your styles. If you want this level of reusability in your css, use sass and create these as placeholders. From there give your dom element a some kind of class(es) that can extend several of these placeholder values.

Ian Storm had a very well written article that hits on this more: http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way-to...

Re: How We Could Write Better CSS

#9
I find that following a prefix method works quite well for organizing a lot CSS. For example (using sass):

    .home-header-h1{
        font-size: 20pt;
        padding: 0px;
        margin: 0px;
        line-height: 1.3;
    }
    .home-header-h1-blue{
        @extend .home-header-h1;
        color: blue;
    }
    .home-header-h1-green{
        @extend .home-header-h1;
        color: green;
    }
This helps keep classes out of your HTML and avoids large amounts of nested CSS. Here's the compiled source:

    .home-header-h1, .home-header-h1-blue, .home-header-h1-green {
          font-size: 20pt;
          padding: 0px;
          margin: 0px;
          line-height: 1.3; }

    .home-header-h1-blue {
          color: blue; }

    .home-header-h1-green {
          color: green; }

Re: How We Could Write Better CSS

#10
post #4

Deeply nested CSS selectors in the source (like the ones in your MixPanel examples) are often a sign of CSS preprocessors in use. Using a tool like LESS or Stylus, MixPanel is probably including mixins in their styles that allow them the same modular flexibility you describe without cluttering the HTML with confusing, non-semantic classes like "mrm". Edit: your site's visual design is awesome, btw

This * 1000.

Just because the output isn't 100% optimal doesn't mean the input isn't sane, maintainable, or clean.

Post reply on HN