Infrequently Noted

Thanks for writing this. Someone needs to be arguing coherently about this, and I'm glad you are. The argument against variables felt flimsy to me, but I wasn't able to verbalize why.

I for one am getting sick and tired, not to mention feeling more and more insulted, by the idea thrown around by the W3C, that CSS _should be simple_, the extent to which that idea is applied seems to imply that the W3C thinks most web developers are morons.

No, it should not be simple at the cost of function. It should be as simple as possible whilst doing what we want - it should not be lobotomised simply to keep it easy to learn.

The fact is that it needs to control presentation, and what CSS can do right now is, frankly, not good enough. It's like trying to paint a masterpiece whilst wearing boxing gloves.

CSS Constants (they are not variables) are simple concepts to get, with huge benefits. There is NO valid argument against them. For me, I'd like to see real Variables in CSS. Not to mention calculations and mixed units.

I'm not interested in fancy-pants shadows and (pathetic) ASCII-art layout techniques (for serious?) whilst we are still fighting with CSS to do the absolute basics like getting widths correct in liquid layouts!

Roll on the day I can do this:

#login

Let me be double clear: CSS's implementations of control concepts should be simple. CSS's abilities should be limitless.

#login { width : (100%-30px); position : absolute(#container); top : 10px; }

I love that idea. That plus constants would make it really really simple to work with CSS.

And as far as my personal experience is concerned, even static sites have CSS files several 100 lines long. Larger sites, the total CSS lines easily crosses several thousand lines. And it is really tough keeping track of colors & shades.

If I could just define a particular color with a set of shades, I could use those constants everywhere without having to keep copying the color code. How is remembering color codes easier than remembering names like: deep_blue, medium_blue, light_blue etc. Constants are used to simlify the code, they don't make it more complex.

I agree with Matt. The suggestion that CSS should be "simple," as in "anyone ought to be able to write it," is silly. CSS is used by web developers. It's not used by Moms and Pops. If web developers have to do a bit of learning, fine -- that's their job.

This is a terrific piece, Alex. Well-done.

Thank you for taking the time to write that. I'm really happy that you countered those "arguments" with solid facts and research. I found it shocking that he would suggest search and replace as an easier way to achieve that. Also, suggesting that I should spend server cycles to patch inabilities of the client is idiotic. But the argument that CSS should be simple was just the last straw: they would have to rewrite it from the ground up to achieve that anyway. And what's with the atrocious design of this guy's web site? I almost went blind reading it.

It did bug me how Bos argues that it's "not necessary" to add constants to CSS simply because there's a different, Rube Goldberg–esque solution (for one platform) that involves running all your CSS files through a preprocessor.

Problems are always "easier" to solve on a part of the stack that's not yours, right?

> it should not be lobotomised simply to keep it easy to learn.

I'd argue CSS is NOT easy to learn now.

If CSS wants to be simple, then it has a way to go - why does a page designer need to understand box models, 'float', and 'clear' in order to make a basic functioning two or three column layout with a header and footer? In practice, they go to Google, search for "3 column CSS" and copy-and-paste the CSS & HTML structure from the first result. That doesn't lead to understanding. Higher-level rules (which are effectively macros) would be a solution to keeping it simple and lead to incremental improvements in understanding. If they were actually serious about making it simple.

But as Matt said, there's no need to lobotomise the advanced practitioners along the way. In the same way a new C/C++ developer can work without macros, they provide flexible and extensible tools for advanced workflows and techniques, and allow developers to build useful functionality ahead of the standards track.

@Robert

It's also not very hard to learn at the moment either. The difficulty today comes from cross browser issues, and those are rapidly becoming a thing of the past.

As for "why does a page designer need to understand box models.." - well for the same reason that the same designer needs to understand the layout grid, basic typography, or any other basic tool of their trade. If people want to be a good designer in any field then they have to understand a lot of surrounding issues and details. I don't think the box model or floats are really any more complex than knowing about good UI principles, or the nuances of good typography, for example.

CSS is simple. It's built out of behavioural blocks that you put together to make something more complex. Think of it like LEGO. Once you understand how the blocks fit together then you can go out and build a replica 14th century town house out of it if you like.

No one expects to be an expert UI designer in a day (or a month, or a year), so why do they expect to be an expert CSS author in a day?

Definitely a fan of "let the implementations lead" - this is long overdue. Thanks Alex.

The fact that CSS even needs something like "!important" is prima fascia evidence that it is poorly thought out.

I’ve been writing code for over thirty years now, starting with assembly language. But even the simplest assemblers had macros which permitted symbolic representation of constant values. This lack of the most rudimentary facilities in CSS continues to baffle me. It is as if all wisdom learned in computer science was just ignored and discarded.

For example, what do we know of modularity? Well the standards principals are that you want modules with high cohesion and low/loose coupling. CSS seems to be just the opposite. Anything that comes later can modify anything that came before in CSS. It's goto gone wild!

Keep in mind that layout elements have semantic meaning to the designer. Wouldn’t it be useful if our layout language let us specify our layout in semantic groupings, not just specify the style of individual elements?

I get around some of these issues by generating some of my CSS dynamical on the server side. In other cases I have tags that get processed when I save the CSS file ... kind of like mail-merge tags.

But for the most part I avoid CSS because my small projects just can't afford testing on every browser version out there and I'm not about to learn the foibles of each one.

And finally, until CSS lets me format my layout in a simple grid, just like a table, without resorting to strange non-semantic markup and obscure large negative margins and other hacks, I will continue to use HTML tables to perform this function.

Peace,

Rob:-]

Plenty to chew on here, and I'll echo the thanks for the time spent researching this before publishing a response.

I think there's a natural tendency for developers to seek convergence in the languages they use. We see it in javascript too - people want it to be more like c/java/python/whatever, and argue passionately about why it should be so. That's the backdrop here for me, and one reason why I'm still on the fence with this issue.

It is certainly true that there's no inherent simplicity in the problem of styling a document or application - particularly when you want one static stylesheet to cover the various permutation and states a page can find itself in. There is a legitimate question though in what portion of that complexity should be accomodated in CSS vs. client or even server-side (post and pre-processing) code.

CSS in the wild is currently crippled by lack of consistent browser support. We haven't begun to exhaust what can be done with it as-is. Something as simple as reliable multiple class (.classOne.classTow) support would revolutionize the way we write stylesheets - we would have much more modularity.

There is a danger of circular reasoning when looking at current trends in CSS use. If people are writing "simple" css today, its likely because that's the only kind its really practical to write. With richer semantics (and good browser support,) more difficult problems could be addressed with greater simplicity.

I am glad to see debate on the matter either way - it is important the evolution of CSS is informed by real experience solving hard problems. If w3c.org was representative of the kind of challenge CSS needs to meet, we'd all have packed up and gone home long ago.

I'm flip flopping for and against with every paragraph, so I'll wrap up. Yes to constants (not variables.) I'm not yet convinced of the need for macros. I do see a need for some means of referencing property values on other elements (the only really useful bit of css expressions). I would like to see relative/proportional values like darker/lighter, thinner/thicker, hue-shifts - in line with the proportional values we have for text sizes already.

I absolutely agree with this article. I am just a beginner web designer and I am already seeing where things could be made much simpler in CSS.

Being able to reference particular objects would be very nice especially for absolute positioning and width declarations.

#login

Statements in CSS like this would make it very, super easy for a beginner to use. I am a beginner, so I carry validity with this statement.

Who styled the W3C site anyway? It is atrocious and hard to read.

Firstly, this is a great, well-researched and argued article.

Secondly, the length of many CSS files (e.g. WordPress) often indicates a lack of craft and poor use of inheritance, on top of excessive and non-semantic HTML markup (div-itis).

Thirdly, I wanted CSS constants so badly after having to plough through thousands of lines of badly-constructed CSS that I made some with good old SSI: http://ecoconsulting.co.uk/training/css_includes.shtml

Clunky, but useful.