CSS Should Be Better

CSS, albeit old, is an amazing breakthrough in the way we can separate markup from how things are displayed. For most newcomers to the web-design arena, this means very little but when you look at things closer, you see it’s doing a lot of things in your favour

Your bandwidth per page drops dramatically as you remove a lot of code from the page
Things become faster for the user once they make it past the initial pageload as they never have to download the style sheet again (assuming you’re using one for the whole site).
Things stay cleaner in your HTML and make it easier to see what’s actually being rendered to the page (something that it pays to check if you develop using something like ASP.NET)
You can group all your relevant styles together so you know what’s making something render as it is.

The last point there is the thing I want to talk about today. Take this CSS for example. Something to change the behaviour of links on a page and remove the underlining:

a.myClass {text-decoration:none;}

The problem is you need to cover all browsers with extra code:

a.myClass {text-decoration:none;}
a.myClass:link {text-decoration:none;}
a.myClass:visited {text-decoration:none;}
a.myClass:active {text-decoration:none;}
a.myClass:hover {text-decoration:none;}

That can be condensed into:

a.myClass, a.myClass:link,a.myClass:visited,
a.myClass:active, a.myClass:hover {text-decoration:none;}

What a dirty pile of mess (Ed - that’s right). Things should be cleaner than this. CSS is supposed to bring the clarity to our lives but making designers write code out like that is just a nightmare to CSS filesize and the overall health of the CSS document. Try reading through a CSS file with 50 different link classes and you’ll find it hard to disagree.

There’s a logical fix for this! Structuring CSS so you can stem and branch off. The syntax is non-existent in the real world, so here’s how I would define it:

a.myClass [
    :link,:visited,:active,:hover {text-decoration:none;}
]

It’s very clear what I’m talking about and how things relate in. I’ve just had a scan over my current style sheet, about 10k in size, and reckon it could cut out a vast quantity of duplicate code… At least a couple of k’s worth.

More importantly, it would let me structure my code easier so I can buzz through it very easily and check to see who let the dogs out when something really does explode and I need to find it quickly. Another example. This time, from the current CSS file your browser is using to render this page:

#menu {/*...*/}
# menu ul {/*...*/}
# menu li {/*...*/}
# menu a, #menu a:link, #menu a:visited, #menu a:active {/*...*/}
# menu a:hover, #menu a.selected, #menu a.selected:link, 
#menu a.selected:visited, #menu a.selected:active {/*...*/}

vs:

#menu [
    {/*...*/}
    ul {/*...*/}
    li {/*...*/}
    a [
        :link,:visited,:active {/*...*/}
        :hover,.selected [
            :link,:visited,:active {/*...*/}
        ]
    ]
]

I’ve taken out the contents from each one just to make the code a little easier on the eye but you can see just from the structure how much easier something like this is to use than rewriting the class names over and over and over again.

Something else that has bothered me is not being able to group collections of behaviours together into one look-up-able group. For example, say you want to have the same font weight and letter spacing in 3 different contexts while still being able to add extra code. Here’s how you would do that now:

#con1,#con2,#con3 {font-weight:bold;letter-spacing:3px;}
# con1 {text-decoration:underline;}
# con2 {padding:20px;}
# con3 {border-right:5px solid black;}

And here’s what I’d suggest:

~share1 {font-weight:bold;letter-spacing:3px;}
# con1 {rel:share1;text-decoration:underline;}
# con2 {rel:share1;padding:20px;}
# con3 {rel:share1;border-right:5px solid black;}

Ok, I’ll admit, the benefit of that example is slightly harder to see from that example. To truly gain something tangible you need the grouping (from the first section) to make it relevant.

The overall target with both these ideas is giving CSS a better grammar that you can use to form better code with less code-duplication and make it easier to keep things orderly… Almost making it an object orientated programming language

What actually happens with this, is something else. It may be being considered already and if it is, all the better, but chances are nothing like this is going to make it to this side of normality (eg be introduced into browsers) this decade. A pity.