Declare and It Happens

CSS already making Web code more approachable

Last week, I wrote about the need to make programming, at least much programming, more accessible. I was thinking in terms of business processes, so spreadsheets and flow-based programming sprang to mind. Today, though, Jeremy Keith reminds me that on the Web, we already have much of that world in Cascading Style Sheets (CSS).

“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.

Right now, CSS is a relatively-straightforward language.

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.


Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
  • J David Eisenberg

    Other examples of this: crontab(5) on UNIX/Linux, where you can specify a “list of times and tasks and makes the tasks happen at the right time.” RPM (the package manager for RedHat) lets you specify dependencies, and the installer finds them. systemd (and upstart) let you specify which services are prerequisites for other services, and then things get loaded as needed in the right order.

    • Samuel Lampa

      Or declarative configuration management tools like Puppet (Maybe Chef too?).

    • Samuel Lampa

      Another thing that comes into mind is the Semantic UI “framework” (or I think it is more of a convention, to be implemented in many frameworks):

      AFAIS, the idea is to use a common vocabulary for describing UI elements, while the actual implementation can then vary across frameworks and implementations.

      Thus, it seems that this takes the declarative nature of CSS to another level. I find it very interesting!

  • Samuel Lampa

    Nice post! I like how it stimulates to re-think some of the indisputably well functioning solutions we already have under our nose, to consider whether not the same approach could be applicable in other areas too. Although the underlying concept of declaratively specify something for sure is nothing new, I think it helps it helps a lot to relate to something that we already know very well how it works out in practice, in all its aspects.

    • Samuel Lampa

      In the end, I think this is all about finding the appropriate abstractions for expressing our designs (or “solutions to problems”) … in other words the hunt to separate the how from the what for each and any of the aspects of a problem, where there is a need to specify a new design to solve a particular problem.

      • Samuel Lampa

        At the same time, there is this question of whether the world as we know it is in fact cleanly separable into different concerns to the extent that we wish, or if in reality it is all very entangled and it is only a result of our limitedness that we are incapable of dealing with more than one aspect at once.

        In biology for instance, I think one can see a bit of both, but on different levels. Firstly, there is definitely a broad separation of concerns most of the time, in that specific tasks are performed by different molecular machines (enzymes), often connected by a physical data flow. On the other hand, all this machinery is encoded on the lowest level in this very entangledness-prone medium called chemistry (which in theory has interaction with everything else in the universe due to how quantum mechanics work).

        So for example, while one can fruitfully simulate protein and enzyme interactions using quite simple models, still in order to really extract the finest details of how some of these interactions come to place, one has to go down to the quantum mechanic level, where really everything is entangled with everything.

        So I guess, as a software developer, while always eagerly learning more about how the “holy grail” quantum mechanics inspired way of solving the software problem, I will for my daily life also try to find some joy in finding and working with the appropriate imperfect simplifications we have today :) (and how they can best be applied and improved, and combined).

        • Samuel Lampa

          Oops, how did this happen? I posted the above message, then deleted it since I felt it went a bit off topic … and now it is shown as posted by “Guest” … funny.