Comment by Groxx | Hacker News Reader

Comment by Groxx | Hacker News Reader

Demo: http://waltschmidt.com/v2/

Link is available on the FAQ wiki page - it should really be on the readme.

edit: I don't think I like it... some details as to why:

  grid.css
  .line:after, .lastUnit:after {
    clear: both;
    content: " x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x ";
    display: block;
    font-size: xx-large;
    height: 0 !important;
    line-height: 0;
    overflow: hidden;
    visibility: hidden;
  }

Anyone care to explain that one? Disabling it causes some sections of the page to overlap.

  grid.css
  .size1of1 {float: none;}
  .size1of2 {width: 50%;}
  .size1of3 {width: 33.3333%;}
  ... etc
  
  content.css
  .f105 {font-size: 105%;}
  .p0 {padding: 0;}
  .p15 {padding: 15px;}
  .pt0 {padding-top: 0;}
  .pt25 {padding-top: 25px;}
  .pl0 {padding-left: 0;}
  .pl15 {padding-left: 15px;}
  ... etc

They've achieved "object oriented" by moving the styles from the CSS to the class attribute. ie, you might as well write `style="padding:0"`, it's the same thing. No doubt HTML-veterans who never really got the whole CSS thing would like it, it's very nearly equivalent to using tables for layout, but with floats instead of <td>s.

That said, I have not used it, or any similar CSS frameworks. Anyone who has care to comment on usability / reusability?

If this is object oriented then his approach can best be likened to multiple inheritance. Because CSS doesn't offer any kind of native inheritence he's forced to redefine each and every class for each instance. This is the equivalent of defining code like:

    var foo = new Animal Brown Quadruped Barking();

Even if styles could be inherited, this seems to be taking the wrong approach. Most of use realise that classes should be used to denote identity, and not behaviour (or in this case, styling). CSS preprocessors seem to fix the same problem in a much nicer way.

    /* Define classes used in HTML */
    .sidebar {
      @include bordered-box;
    }

    #special-offer {
      @include bordered-box;
      position: absolute;
      top: 0;
      right: 0;  
    }
     
    /* Define theme information */
    @mixin bordered-box {
      h3 {
        background: red;
        color: white;
      }
      border: 1px solid red;
    }

That multiple-inheritance comparison as you showed it is just about perfect, thanks! And yes, preprocessors make a ridiculous amount of sense. That mixins and variables aren't part of CSS seems almost like an oversight.

At least there's Less. Anyone use it, or know of a better system?

I have tried out both Less (http://lesscss.org/) and Sass (http://sass-lang.com/), but not used either in a big website. It looks like Sass is better – it is more powerful in that it supports more functions and you can optionally use an alternative, less-redundant syntax with significant whitespace and no semicolons. The 2009 post http://nex-3.com/posts/83-sass-and-less by the creator of Sass compares the two, and the two deficiencies in Sass mentioned in that post have since been fixed. From what I can tell from looking quickly at the Less website, it hasn’t really improved since I last saw it. I’m using Sass for my very simple personal website, and it works fine for me.

She has a blog post explaining the x's here:

http://www.stubbornella.org/content/2010/12/09/the-hacktasti...

Edit: I also agree with your sentiment. This seems to move away from what CSS classes are intended for, and gives things naming conventions that are tied directly to their internal CSS code instead of to their semantic meaning on the page. That said, I haven't used it either, so maybe it's way better this way, but something doesn't sit right with me.

I think the point is that structure and style should be decoupled, i.e. the way something looks (color, fonts, borders, etc.) should be defined separately from the way something is shaped.

I entirely agree they should be decoupled; so why are they being combined by having you write what's essentially inline CSS in your HTML? I thought the point of CSS was to do away with that, because of how inflexible it was, and to move to a more declarative setup.

This would undoubtedly have a negative impact on performance, no?

I don't know... few classes in the CSS but tons of classes in the attributes vs tons of classes in the CSS but few classes in the attributes. I somewhat doubt it minimizes layout calculation much, many styles are still being applied to many DOM nodes. Memory for those classes, maybe, but I doubt lookup costs very much compared to other parts of rendering a page.

Though I would be interested in seeing some profiling data demonstrating one way or the other. Even if it's relatively transient data, as it relies heavily on the rendering code.

Reply on news.ycombinator.com