Reusability And Non-semantic Names

Recently, a lot has been said about CSS frameworks and non-semantic names. It is quite true that a CSS framework like Blueprint or YUI Grids gives you non-semantic names. I am not even going to venture into whether it is good or bad, this seems to be a subjective topic. But I want to go to the reason for having to use the non-semantic names. By non-semantic I understand that they do not convey purpose in the design’s context.

It is reusability people! And this is not true only for the CSS frameworks, it applies to all frameworks and libraries. Software engineering principles and best practices like DRY ask us to avoid duplicate code and reuse. As time progresses we gain more granularity in what we want to reuse and we need to give a name to it, using which we identify it. And I have seen that most of the times they turn out to be non-semantic names in context of the design or application. For example, a function named concatenate can be used by an address book application as well as in a small program for printing out the Fibonacci series. And concatenate is non-semantic in both the contexts.

However, it is not non-semantic in its own context. It says what it does. The point is that the more you want to reuse, the more you have to come up with context-independent names, which end up being technical and non-semantic in an application or design specific context.

Similarly, a CSS class span-2 does what it says, but it is not specific to the layout you are creating. Similarly you can have a class called floatleft which uninnovatively only floats elements to the left. These classes let you separate every individual aspect and give a name to them so that they can be selectively used. Is it bad? I would not say so. In fact I think they are great because you can control that aspect while you are authoring the markup, which might or might not be good things depending on who is doing to do it.

Nor do these class names force you that you cannot apply additional semantic classes to the element. And I think this is what will happen in most cases. Either the non-semantic names get accompanied by semantic CSS IDs or classes or through hierarchy.

I find this true about all frameworks – design, programming, CSS and even process. Any framework is going to be full of names used in that domain, and they are not always going to be specific to your design. Aren’t they more non-generic than non-semantic?

I have my own concerns of using libraries and frameworks, more to understand when to use them and when not. Or I might get too pedantic to call some of them libraries and not frameworks. But non-semantic names should not be a reason to not use them.

Discussion [Participate or Link]

  1. Use HSS To Use Variables In CSS | iface thoughts said:

    […] variables Nicolas has perhaps lightened the argument of non-semantic CSS names in CSS frameworks. Reusability tends to create non-semantic names, and having variables to reuse values will help us skip the non-semantic CSS names. Instead of […]

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.