(in /private/var/root/haml)
dyld: NSLinkModule() error
dyld: Symbol not found: _RARRAY_LEN
Referenced from: /opt/local/lib/ruby/gems/1.8/gems/ruby-prof-0.7.3/lib/ruby_prof.bundle
Expected in: flat namespace

Trace/BPT trap

My hackish fix was to uninstall ruby-prof and then re-run the ‘rake install’. Just posting here in case anyone runs into a similar problem

Thanks so much for creating this post. Like you I have been attracted to grid based css frameworks, but have been extremely reticent to add the purely presentational markup to my (x)html pages.

I’m going to grab your example and adapt it to my current layout project, as soon as I get home tonight.

@Marty – what you’re suggesting “just renaming them ourselves in the CSS, simply doing a text replace with more semantic names?” won’t work cleanly. Consider the case where two semantic elements in your code use .grid_4 layout — say a callout box, and an ad container — you don’t want to give them the same class name, because you don’t want to permanantly constrain them to be the same size, however, in the current layout they are the same size. Using your suggested text replace plan, there’s no solution other than to use some ‘presentational’ name. Might as well leave it as ‘grid_4′ in that case.

What Aaron’s method does is leave you with

.callout {
/* your custom styles */
/* grid_4 styles */
}

.ad-container {
/* your custom styles */
/* grid_4 styles */
}

What non-programmers such as yourself would probably use is a simple ‘include’ syntax, like this:

.callout {
/* your custom styles */
@filter-include(framework-name, grid_4);
}

.ad-container {
/* your custom styles */
@filter-include(framework-name, grid_4);
}

Run the file through a filter to transform your input css into a final merged css.

I like where it’s going though. What I could see working is some kind of intermediary where I could somehow easily type in ‘.content = .container_12′ and then I could just use class=”content” or ‘.menu = .grid_4′ and so on. Does that make sense? Seems like those would be easy enough strings to parse with a simple script.

But would any of this save any time over just renaming them ourselves in the CSS, simply doing a text replace with more semantic names?

Thanks for the reply. I hear your point about the heavyweight ascription of “code” to Sass. My goal was to show how Sass enables one to employ “coding” best practices, whether they be culled from scripting practices or more robust traditional software engineering practices. Sass is definitely lightweight and straightforward to pick up.

@Woody:

Thanks for the comment. My main point in the article was to show how you didn’t have to sacrifice the semantics of your HTML to use CSS frameworks. Also, as I tried to show, I don’t think Sass produces convoluted CSS at all. I think the DSL does a great job of providing a variation on CSS that will allow anyone familiar with the latter to easily transition to Sass. True, you might have to deal with a few abstractions, but for me that doesn’t necessarily equate to convolution. Further, it’s up to the developer to decide if he or she wants to leverage Sass’s scripting capabilities. Likely, if he or she isn’t interested in building modularized, reusable Sass libraries, the Sass files won’t look much different than regular CSS files. In the end I proved to myself that there is no sacrifice necessary, one can maintain his or her semantic HTML and gain access to, I would argue, more expressive CSS via Sass.

I do feel strongly that semantic (X)HTML is a benefit to the web community. The purpose of a document is to describe the structure of meaningful data. Semantically viable markup reaps benefits in areas like web standards, accessibility, and SEO. There is no real reason the markup should be cluttered with presentational concerns. I would argue that it is the conflation of semantics and presentation that is convoluted, rather than vice versa. I’m not entirely sure what you mean by “just text”, if you can explain further I could more readily address your question.

To reiterate my view, HTML should be meaningful and independent of any presentational context. It’s exactly this separation of concerns that gives designers the power to employ CSS and craft myriad final presentations of the markup on varied client platforms.

Regarding the bloat that comes from prevalent use of mixins, I can tell you that if you use gzip compression, there’s almost no difference in file size of the compressed files. Also, it’s quite likely that a future version of sass will contain an optimization step that combines styles and selectors where possible. Lastly, it’s certainly possible to hand optimize your stylesheets using some of the lower-level mixins like +grid-unit-base if you want to.

Despite the few reports to the contrary, I can tell you that Sass scales to large sites very well. I know because I run one (6.7k lines of sass, in 61 files). It is the use of abstraction and encapsulation that makes maintaining these stylesheets easier — not harder.

Great post! Thanks for spreading the word.