Simon Kenyon Shepard :: justLikeThat.

Usually when I have an idea, I try to code it first, then often I get half way through and get side tracked by something else and the idea never gets finished and so I never get to write about it. This time I thought I would experiment and write the idea up first before writing any code, and then if I never get to write it and it becomes famous, at least I can say, “Well, I thought of that ages ago”.

I’m a big fan of Dan North, especially some of the concepts he pioneered like BDD. It really changed the way I thought about code, writing literate programming may have been around for some time but this was the first introduction I had to it.

I’ve also been around presentation code and CSS for a long time. In fact it was one of the first declarative languages I mastered. When I was earning a living through CSS, it was more of an artform, a careful balance between unrealistic requirements from print turned digital designers, browser quirks, performance and simplicity were all key to creating what you could call clean code.

Now, the challenges are different with CSS, you don’t have to worry so much about cross browser quirks as the older out of date browsers have less influence. You can use more CSS3 properties that take away a lot of the old pain of for example rounded corners and enable more of the print designs to be created. Performance can be automatically optimized with compressors, but you still have the problem of the language of CSS.

There have been some attempts to make CSS more like a classic programming language following the tenants of inherence and mixins. To be honest I think this misses the point.

The most common use of CSS is to enable a coder to convert the static designs of a designer into a working web site. But the static designs are only part of the story. In agile we say that a story card is a place holder for a conversation. When you start every story it is your job to go to the designer and have a conversation. That conversation transfers knowledge about the design. For example, you might go and ask for the specific hex colour of a module or the number of pixels padding it has or the radius of the round corners.

Then you convert that data into CSS. So CSS is already a DSL, just not a very good one. It does not satisfy the programming domain and it does not satisfy the design domain. So ok, we could go the way of less and try to make CSS more like a programming language, but why not go the other way like we do in BDD? Why not let’s use natural language from the design domain to help us create more readable code that generates CSS, code that the designer and programmer can use alike to achieve their goals.

Introducing DDCSS, or Design driven cascading style sheets.

Lets take the following element of design from a famous website:

Now in terms of CSS, it would look something like this:

.moduleA {

    border: 1px solid red;
    margin: 0 10px 5px 10px;
    padding-top: 10px;
    width: 200px;

}

Now in DDCSS it would look more like this:

    ...
    a generic Module A has
    a 1px solid red border,
    a 0 margin-top,
    a 10px margin-left and margin-right and padding-top
    a 200px width.

So, not much difference so far, Why bother? Well, how often is CSS this simple? More likey, you do this CSS and then it doesn’t work in a certain scenario, so you go back to the designer and you find out a variation. Then your code begins to look something like this:

.moduleA {

    border: 1px solid red;
    margin: 0 10px 5px 10px;
    padding-top: 10px;
    width: 200px;

}

.situationB .moduleA {

    width: 150px;

}

And this is where DDCSS starts to look better and much less terse than the raw CSS.

    ...
    a generic Module A has
    a 1px solid red border,
    a 0 margin-top,
    a 10px margin-left and margin-right and padding-top,
    a 200px width,

   Given Module A is inside Scenario B
   Then Module A has
   a 150px width.

Now using a DSL more like this, we could start to easily share code between our designer and programmer. What’s more is it creates an easy accesible way for the two to have a discussion, if your DDCSS is starting to look really messy or there is a lot of repetition with only tiny changes, then maybe it time to take it back to the designer and say we have a consistency problem. Not only that but it’s something you could take to a third party like a product owner to look through and have discussions about what could be changed. Finally I allows small changes to be edited directly by the designer. It becomes both a code generating style guide and a reference to write tests against.

So, finally, now I’ve written about it - anyone interested in building it?