“Being a programming language” was never a goal for CSS, which pushed the opposite direction in contrast to Netscape’s JavaScript Style Sheets. There are moments, of course, when developers wish otherwise, and the SASS and LESS preprocessors can give them more functionality. As Keith points out, however:

There are a lot of really powerful programmatic concepts that we could add to CSS, all of which would certainly make it a more powerful language. But I think that power would come at an expense.

I suspect some readers are scratching their heads, wondering why CSS is even being considered a language, much less why adding programming features to it would be a bad thing. If you think of CSS as a simple object-manipulation language, though, it fits pretty neatly into the sweet spot I described last week.

It may seem like it lacks control structures, but that’s because CSS does something trickier: it uses selector precedence as a tie-breaker, but it largely lets the documents to which it applies determine how the cascade works. Documents can reach out to a complete stylesheet, or contain bits of style information themselves, or users (and software) can apply their own stylesheets. However many modules are applied, the basic logic of CSS selectors will sort out what gets applied (or not) to which parts of a document.

I’ll grant that CSS has some issues, like a box model whose replacement many developers eagerly await and a high level of repetition that currently requires preprocessing to reduce. Some of its more recent challenges have pushed its syntax, as Keith notes. Its core processing approach, taking full advantage of the declarative nature of its selectors, though, hits a sweet spot. As Scott Kellum describes it, “you declare an element has a style and it happens“.

Spreadsheets, last week’s suggested sweet spot, are also fairly though not completely declarative. You can read =B1+B2, as the imperative “calculate the sum of B1 and B2″, or by starting from the equals sign and saying “what goes here is the sum of B1 and B2″. The functions and operators (and potentially extensions and scripts) carry the imperative weight, leaving the formulas themselves to be declarations of what should fill a space.

Unlike spreadsheets, CSS lacks much of a user interface. Despite being used to create attractive interfaces, CSS is still a text file with some odd-looking syntax. Somehow, though, that odd-looking syntax combined with some HTML (itself an odd-looking declarative syntax) and a browser with a refresh button is enough of a welcome to bring many people a step closer to controlling computers. It may be simple code, but it is certainly code.

Can we push this further? Can we imagine a data-processing language that applies similar rules to incoming data sets to perform simple transformations? Can we imagine systems that take a list of times and tasks and makes the tasks happen at the right time? Or systems that take a list of possible sensor stimuli and appropriate responses?

All of those are workable. Many of them already exist in some form. True, there will still need to be programmers writing the code that responds to these requests, the interfaces among various levels of code and hardware. Complexity grows with demands for more and new possibilities. However, by separating out the “you declare [something] and it happens” part from the details of making it happen, we may be able to bring more people into the code conversation. If they want to learn more details, wonderful. If they don’t, they can still get a lot done.

Update: In conversation after this was posted, I wrote that to “look for programming languages that actually fit human beings’ expectations instead of computers, the place to go looking is precisely in things that weren’t built for programmers, don’t muck about with variables, etc. ” In some ways, that explains why it’s difficult for programmers to create these kinds of languages: it’s too hard to imagine value in a language missing the parts programmers hold dear.