James Cat's rough && ready blog

All new section on CSS architecture

Posted in css by zzjames on August 7, 2013

I’ve been asked by friends about OOCS, to explain it, also SMACSS -> the two have their similarities.

I like to understand things in a principled way, I like diagrams, I sort of like set-theory – I was wondering to myself if I can at least try to understand CSS in a principled way, using set theory (and diagrams). This is my thinking so far.

CSS syntax, according to the WC3 is ‘a series of qualified rules’ – and a qualified rule ‘has a prelude consisting of a list of component values, and a block consisting of a simple {} block’

for example

prelude {}

The WC3 spec goes on to say –> “Note: Most qualified rules will be style rules, where the prelude is a selector [SELECT] and the block a list of declarations.”

Now this is as far down the WC3 rabbit hole I’m going to go for now. This is all we need for our basic set-theory analysis.

the prelude, or selector, can be thought of as a pointer or label, an abstraction which represents the SET of declarations, they also represent an INTERFACE to the style-sheet, as they are the only public hooks to the style declarations within the style-sheet.

The CSS can be said to ‘export an interface’ in the same way that a C library exports an interface, or a PHP5 object exports an interface (it’s public methods) through these PRELUDES.

The list of declarations within the {} really do have a lot of similarities with a mathematical set, for example if you wrote :

S is a set consisting of {1,2,2,3,4,5,6,6}

the resulting set would be {1,2,3,4,5,6} since repeating elements are not allowed in a set – such things ARE allowed in sequence, e.g. S is a sequence consisting of [1,2,2,3,4,5,6,6] would really be a case of ‘what you see is what you get’

in a similar way the list of declarations only allows one property declaration per type (for obvious reasons) e.g. {float:left; margin: 0; float:right} is {margin:0; float:right} -> the property declaration lexically ‘last’ (in the left to right, top to bottom regular way) overrides the earlier one.

So we have a collection of ‘sets of property declarations’ which have labels that point to each sets.

css represented as sets

css represented as sets

The labels interact with your HTML code, ultimately determining what set of styles get applied to what HTML element.

There is a hierarchy of selectors, this is called ‘selector specificity’ – this ultimately determines the precedence of the final set. For example <h1 class=”shiny-heading”> will attempt to apply all the styles pointed to by the label h1, and all the styles pointed to by the label .shiny-heading.

In this case h1 styles are prefered over .shiny-heading, but if there are rules in .shiny-heading not overwritten in h1, they will be applied. This is the ‘cascade’ which gives rise to the name ‘cascading style sheets’.

Specificity rules can combine to make quite a complex an unpredictable ‘interface’ to the sets of styles, which is why, aside from in a basic ‘reset’ style sheet both SMACSS and OOCS generally tell you to stick to classes as the main way of creating your style-sheets API – unlike in Marxism, in CSS all classes are all equal.

This specificity not to be confused with inheritance, which is where child elements of a element in the DOM (e.g. <p> inside <div>) inherit styles, that is something different.

Confusingly, it’s classes and inheritence of a different kind that I now want to talk about – and that’s the inheritance of classes in object oriented languages.

OOP languages can be thought of as sets – sets of methods and properies, usually pointed to by an instance variable.


ListMaker bob = new ListMaker();

will create a set of properties and methods pointed to by the variable bob.

So here we start to see the similarities between OOCSS and OOP – I’ve read many rants online that it’s a crime against acronyms to regard CSS as in any way ‘Object Oriented’ but I hope you can see that with the right paradigm, it really can be – no one ever said ‘it has all the features of an object oriented language’ just that it can be seen as ‘object like’ thus, object oriented.

The powerful idea in both OOP and OOCS is to reduce redundancy by designing re-uable functional units, in the case of OOP reusable units of program, in OOCSS case reusable units of visual design.

In order to create good code in a OO language, object types (different sets – called ‘classes’)  must be identified prior to coding in an analysis phase, during this phase (in theory although often not in practice!) all the different kinds of objects (classes) are identified and their functions and data are determined, the analysis phase ends and a construction phase begins, this is the first iteration (in an agile style development lifecycle) – often this process reveals short-comings in the analysis phase, so a with that new information a second analysis phase happens, and the objects types are modified, new objects types are created and old ones modified or deleted altogether. Then construction begins again. The point to note here is that object types are not elucidated during construction, you must revisit analysis to create/modify/delete objects.

OOCS and SMACSS have a similar methodology, you don’t simply throw your CSS object types together, you need to carefully analyse your design, and elucidate what ‘sets of styles’ you can see repeating in the design, for example, in Nicole Sullivan’s analysis of Facebook’s design she found 1000s of occurrences of what she called a ‘media object’ a two column block, the left column is always an image, the right column can be anything, including another media object – they can be any size, but they all shared this 2 column image on the left pattern, which can be described in CSS, no point in continually adding the rules for that in lots of different places, just create a set containing those rules and apply it wherever you want ‘2 columns with an image on the left’ – of course you can mis-apply this to the wrong kind of HTML elements, it’s not magical, but she found it massively reduced duplicate style declarations in the CSS. There’s a youtube presentation about it called ‘top 5 mistakes of massive CSS’

So finally I want to mention OO inheritence. Using set theory diagrams lets look at a class->subclass relationship in OOP of ‘mammal’ class and ‘dog’ class.

OOP classes as a venn diagram

OOP classes as a venn diagram

Here we see that mammal class contains the dog class. the dog class in fact ‘redifnes’ an area of the mammal class, it can, and often does (although not shown in this diagram) extend the mammal class also.

The dog however, basically remains a mammal, because of the way OO languages treat the inheritence relationship, any functionality not provided by objects of type dog are delegated to the ‘super’ object of type ‘mammal’.

This is similar to the way ‘sets of style declarations’ can be used in CSS, we’ve already spoken of the cascade, if we stick to using classes for defining our sets, the cascade rules are simpler. For example

login-box {
background: grey;
padding: 6px;
border: 1px solid black;
width: 25%;


can be a set of style rules, and

login-box-small {

can be another set. However, when applied to a html element:

<div class="login-box">.....</div>

and somewhere else in your site:

<div class="login-box login-box-small">.....</div>

you get begin to use the cascade in a way that mimics at OOP class inheritence way – it’s not as elegant, because there is no way of declaring that login-box-small really is a ‘sub-class’ of ‘login-box’ so both must be specified, but it goes some way to eliminating having to repeat style declarations, and gives you a fairly robust model on which to analyse your design.

In the end you’re declaring sets of styles, and giving them a label. The label is an API which hooks into HTML – the architecture of this API can be made to be reusable, maintainable and cut-down on excess duplication, but this means designing the CSS by analysing your design, similar to the way OOP works.

Well, it’s the theory. Good luck, let me know how it goes. 🙂

One Response

Subscribe to comments with RSS.

  1. James said, on December 4, 2013 at 5:28 pm

    I can see now, that in the login-box example, in this case, it would perhaps be better to define the set containing the single style declaration, width:15% as a class ‘narrow’ – but there are many cases where the pattern I use is a logical choice.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: