Blog This!   Lee Geistlinger's Web Log

Blog Home
Blog Archives
LittleGhost Home

E-mail: geistlinger AT gmail.com

Everyone loves lists Books, Movies and so on

My Online Aggregator

CSS Thoughts

There has been a lot of buzz about CSS lately, especially on blogs. RSS is the main subject these days, but CSS gets a fair amount of play, as well.

Interestingly, I don't think I've ever read an article that said "Don't use CSS" or "As supported today, CSS sucks" or whatever. That just occurred to me. Interesting...

Anyway.

I like CSS. I thinks it's powerful; I know it's the future (like it or not).

I also find it frustrating and limiting.

The frustrating part is familiar to anyone who has used styles, but I should explain "limiting": By this I mean the things that CSS just can't do - that it is not designed to do, and no matter your hacking, it won't work.

An example of a limit would be that the code itself (a style sheet, say), cannot do browser detection. The server/scripting language (usually JS) does this. Something has to do it in many cases, in any case, as different CSS files are sometimes served up for different browsers/platforms. Not the end of the world; CSS is not supposed to be a proceduaral language - it's just a formating sheet. (Note: I would not want CSS to support this type of programming. Why? Doesn't belong there. I just use this as an example that is pretty clear.)

OK.

That said, I do miss variables in CSS files.

I really, really miss them.

For example, how many times have you built a style sheet using, say "#cc3366" as your "red" color. So it's scattered all over the style sheet. Then the designer decides for a more pure red, so you change #cc3366 to #ff0000 all over the place.

No biggie, but let's take this a step further: You're building a portal type product, where users can customize the look and feel (i.e. the style sheet) to a degree. Suddenly, you're changing the red, the bold blue, the green footer links and so on all over the place.

And how do you do this?

• Each user gets his own style sheet (tied to a cookie ID, say), which is re-built and saved in the file system each time the user changes the UI.


• Use of "themes" where a use can pick - but not alter - from a finite list of style sheets. Then the scripting language can merely include "meadow.css" or "metal.css" per user's selection.


• Base style sheet everyone uses that is actually - if using PHP, for example - a ".php" file. The user's color choices are again stored in a cookie, and the style sheet is parsed and included with each page the user calls.

None are terribly good solutions (admittedly, a portal-type site is not a normal site).

I see a "metaCSS" file that contains variables that are used as defaults (where no overrides exist) in the given CSS file. A file might look like:

<metaStyle>

font-family: arial, helvetica;

$red: #ff0000;

$green: #99cc99;

font-size: 13px;

</metaStyle>

Or whatever - but these would essentially do two things:

• Provide defaults (all fonts would be "arial,helvetica" and "13px" unless overridden


• Provide variables: a line in the css file that reads "background-color: $red;" means that the background color there would be pure red (#ff0000).
  

Yes, you can pretty much do this now - with the third portal example (above) - but it requires parsing and including on each page. And one of the nice things about CSS is that is only loads once per session (unless changed); the parse-per-page ruins this gain.

I see a need for this coming, especially with XML on the ascent: XML is pickier, validation is an issue. By putting all the variables in one place, you can guarantee that each class/id will have a default font family etc...

But that's a pipe dream (or is it?....)

First, let's get CSS supported and working so positioning actually works well and consistently.

And that's all I have to say about that...