a companion discussion area for blog.codinghorror.com

What's Wrong With CSS

#1

We're currently in the midst of a CSS Zen Garden type excerise on our family of Q&A websites, which I affectionately refer to as "the Trilogy":

This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2010/04/whats-wrong-with-css.html
#2

There are actually a few strategies that you could be using to help out here:

  • Use a series of multiple CSS files with different levels of reuse: a global CSS file with core layout, header, and text; a page level CSS file for styles specific to that page; and maybe even a widget level CSS file (this usually ends up inline though). Then when you have a family of sites, you would also have override files that gets applied after global.css, page.css, and widget.css, such as global_stack_overflow.css, etc. This way you can simplify the management of many different styles.
  • If you’re finding the need to copy and paste a color everywhere, you might be doing things wrong. This is what CSS classes were designed for. You can separate out your “look and feel” classes from your layout classes. This way you can reuse things like color, which fall in the look-and-feel category.
  • Lack of nesting, I’m not sure what you mean by this. Could you provide some examples? You can use CSS selectors to apply a style to a div, or to nested divs. You can also apply multiple styles to a single div or class. Where would nesting come into play?

I hope this helps!

#3

Hey Now Jeff,

Very good post! Thx 4 the info

Coding Horror Fan,
Catto

#4

In the classic asp days I would just run the .css files through the asp.dll and put asp code in the .css file. I would call functions and stuff :slight_smile:

Can you do something similar in .NET?

#5

It would be interesting to create a serverside library that:

  • Handles translation of LittleCSS/Sass to regular CSS
  • Supports multiple CSS files
  • Combines the CSS files into one file
  • Minifies the one CSS file and Gzippes it
  • Sends the correct headers
  • And of course caches everything server-side.
#6

I want to emphasize the first two points Michael makes, especially the first one. Since many sites are built with a base layer that is the meat and potatoes of the layout (perhaps contains header and footer) this structuring of files works wonders for management.

Thanks for the post. It was getting a little quiet around here!

#7

I’ve been using Sass for a while, and I usually set it up to dynamically generate static CSS on the first request and serve up the generated CSS on subsequent requests.

Sass’s color math and mixins are amazing, especially when combined with something like Compass: http://compass-style.org/

#8

You should check out .Less, which is a .Net port of Less CSS, and more specifically Phil Haack’s T4CSS templates to do it at compile time with minification:

http://haacked.com/archive/2009/12/02/t4-template-for-less-css.aspx

#9

A colleague just pointed this out to me - very cool. I’d rolled my own solution along similar lines, but it’s not as comprehensive - so now I’ll need to figure out a way to transition my existing style sheets.

FWIW there’s a .NET port of .LESS here: http://www.dotlesscss.com/

People have been clamoring for CSS variables for years, but there are what seem to me to be good theoretical reasons not to do this; see http://www.w3.org/People/Bos/CSS-variables

I think that server-side or author-side solutions along the lines of .LESS are going to be the best solution to this problem for the foreseeable future.

#10

I have to agree with Michael Hagen. Although CSS isn’t perfect, there are several ways to reuse such as using multiple classes on an item and using multiple files such as a global file.

I have been frustrated with CSS myself, and although it falls short of DRY and does require some weird nesting, you can get fairly close to DRY with the structures implemented in 2.0.

#11

Seriously though, while I agree with your comments, HTML itself is seriously breaking DRY just as much as CSS does. How do we combat that? We use some kind of template language. My weapon of choice is usually PHP, but regardless whichever you choose, as long as it spits out CSS it should be just fine.

#12

Next version of Less will be directly in js (still alpha atm)

http://github.com/cloudhead/less.js

/me curious of performance, but should be great

#13

So glad people are noticing CSS metaframeworks, the King of All @media

http://www.slideshare.net/pengwynn/css-metaframeworks-king-of-all-media

#14

I would second the recommendation for looking at Sass’ math capabilities. Using it, you could even further reduce your work by setting a couple of “base” colors for your palette and having the math compute variations of the colors for lighter/darker borders, backgrounds, etc.

#15

I’m pretty sure Nicole Sullivan’s OOCSS (http://oocss.org/) addresses the issue of DRY.
You just have to keep giving multiple class names to your elements.

#16

@Michael Hagen - While it's true that you could do something like

.Blue {color:#0000FF}

and then

<h4 class="Blue">…</h4>

… it's a really bad idea for a number of reasons. And there's not any way to do math on the colors (e.g. @blue + #111), which is for me one of the biggest draws of server-side CSS generation.

#17

Austrian levels of discipline? Beeing Austrian I like this, but never heard of it before :slight_smile:

I totally agree that CSS is hugely annoying for certain layout tasks. I’ll just continue to use tables (GASP!) in these situations. Why use CSS and resort to hacks when there’s a clean, simple solution using tables?

#18

Hey Jeff, thanks for the post! I never heard of Sass, looks awesome!

#19

The important thing about SASS/SCSS (I don’t do much with less) is less about the variables and more about the mixins and now inheritance. These let you use semantic class names on the page while building a stable, debugged, reusable library of style rules. Building this library is what really gives you a leg up in speed/maintenance and because it’s pulled in as necessary, you can make the rules as extensive as you like. It really boils down to how clever you are at designing abstractions. I’m still working on it, but mine handles all my layout and typography norms as well as simple color handling (color schemes tend to vary more between projects) and I’m working on integration with yui3 so my preferred styles flow down into the CSS used in the widgets.

I was doing CSS using the techniques Michael recommends in the first comment for years but the boost in switching to SASS was huge it’s a lot like writing javascript with/without a framework back in 2005. There’s a definite benefit but things aren’t solid yet. I am pleased that I’ve done a few designs now where I’m happy with how it looks in Firefox, fire up the VM and take a look at it in IE and IT JUST WORKS.

#20

To stay DRY, you need to add a layer of abstraction to your deployment process. Sure CSS is lame, but making it a full-blown programming language is not the best solution.