At What Point Do Semantics Not Apply?

Published 6 years 7 months ago on September 17, 2007 — 5 min read

There was a large response to the article I posted a couple weeks ago, Please Do Not Use CSS Frameworks, which for the most part was evenly divided. There are many people who support and stand behind both the creation and implementation of CSS frameworks. They truly see the benefit in saving time in development as well as having a more structured environment in which to work.

I can absolutely see the benefit to a CSS framework in that regard, and I think that’s where my sensational title of a couple weeks ago skewed the tone of the entire article. Some readers (understandably) felt that I saw absolutely no worth in a project such as a CSS framework. That’s not the case, entirely. I simply see some issues that could be counteractive, and those issues can [usually] be applied to nearly any framework in existence.

Frameworks are a fantastic idea, fantastic, but I’m sure we can all agree that there is an extremely high potential for ‘learning the framework’ as opposed to learning the language itself. This is a major issue to keep in mind, especially with something like CSS. One of the other issues I’ve got with the implementation of a CSS framework is semantics.

Semantics and CSS? Applicable?

The resulting discussion surrounding the release of Blueprint itself has been utterly fantastic. Many great minds have left opinions on the release. The pros, the cons, the ridiculousness surrounding the reaction of such a release. I’ve tried to read as much as I can of this conversation, and some interesting ideas and thoughts have come up.

One of the more interesting points brought up was that surrounding the semantics of class and id names. While I feel that semantic value can be given to a class or id, other developers thought it was simply ridiculous, that they are there to act [more-or-less] as hooks for CSS and JavaScript. Others felt that the classes and ids used in Blueprint are applicable because values such as .prepend-8, .pull-2, and .span-22 were spot on in their use.

My stance is the following: if a class or id can be given a more descriptive value, why not? While some developers feel that it is the markup which needs to be semantic, I can see a value in trying to create more semantic classes and ids. Microformats are a prime example. Microformats may not use values which are initially obvious to their meaning, but their objective is such. Microformats use classes in an effort to better define data in a semantic way. Why not try to carry this over to the rest of your document?

From what I can gather, it seems as though some developers feel that trying to create a semantic class or id is just silly. What do you think? Is a class little more than a hook for CSS to apply some style?

Are semantics applicable with only an associated meaning?

Microformats make sense to those who have worked with them before. Each class has a meaning because there is a large set of documentation to back it up. Without that documentation, would the class still be semantic? This same issue carries over to Blueprint. At first glance, the classes used are awkward and seemingly meaningless — until you read the documentation. Is it at that point they obtain semantic value?

I think to those who have come to accept and use Blueprint on their projects, there is a resounding yes. This concept (and reaction) is closely related to Microformats; some people agree, others don’t. If you’re familiar with the framework, Blueprint has attempted to keep class names partially semantic.

So, what’s the problem?

While the classes within Blueprint attempt to retain semantics when taking the entire framework into consideration, it does so only to provide meaning for the visual elements involved. It is literally impossible for Blueprint to take into account the actual information presented. I think this is where the issues regarding semantics come into play.

Is there a divide when taking into consideration the semantics of (X)HTML versus the semantics of classes? Are they one in the same? (X)HTML has a set of defined tags, each of which inherits a meaning. CSS is different entirely, allowing the author to define much of which comprises a completed stylesheet. It is up to the author to understand a meaning applied to any class or id he chooses. Can semantics still be applied? In my opinion, yes they can. When I’ve got a project in front of me, I’ll try to best define the provided information using meaningful classes and ids not only to help me remain more organized, but also in an attempt to help others on my team get up to speed quickly when working with my markup and style.

I’m really quite curious to hear how others feel about this ‘situation’. Are semantics completely inapplicable when it comes to CSS? Do you feel as though trying to create semantic classes is simply overzealous? Without the structured definition and documentation of (X)HTML to back it up, is CSS better left to be implemented on a ‘what works’ basis? Are semantic names that only describe visual orientation as meaningful as valuable as those which describe the informational meaning? Do you feel this topic is just beating a dead horse? Please, provide your opinion.

There's a conversation brewing

  1. I think, classname and id (or just «elements naming») — it’s the second layer of XHTML semantic (first — elements, third — microformats). Some kind of CSS-semantic — using margin-bottom to divide elements instead of border-bottom.

  2. Semantically naming everything means that you have a self documenting system which helps everyone who has to deal with it. Yes you could just call your classes and id’s a1, a2 a3 etc but why?

    That’s not helpful now and it won’t be helpful in 6 months time. A program could create better names and if that’s the case then we’re asking to be replaced by software. Web design and development are crafts that take time to learn – you don’t find many of the top paid in the business using dreamweaver wizards, they know how to achieve the ends they want and don’t rely on automated tools for that.

  3. One of the things that I always have in the back of my mind is “If someone, including myself, were to look at my CSS six months from now, would they be able to easily make sense of it?” As such, it makes sense — too me, at least — to think at least somewhat in semantic terms when picking my class and id names. If I’m dealing with the main navigation of the site, why not use something like “main_nav” or “primary_nav”?

  4. If we’re talking strictly about the purpose of different layers of the application, the CSS would just be for _style_. You make a strong point when you mention Microformats, but Microformats really are just a way of making up for the shortcomings of XHTML. Arguably, the deeper meaning provided by Microformats should be implemented into future versions of the markup anyway.

    This whole debate is near and dear to me as we’ve been deciding whether to implement a CSS framework for a new version of our site. While I’d much prefer to build everything from scratch, the project parameters are basically, “design for everything we haven’t even imagined yet.” We don’t even have Photoshop mocks of the pages yet, but we’re supposed to be progressing on production.

    You could certainly chock a lot of that up to bad project management and poor business processes, but that’s the unfortunate reality at a lot of companies. As a designer working under less-than-ideal circumstances, I’m thankful for tools that provide flexibility and a consistent approach. If CSS frameworks don’t go the extra mile in adding more semantic value, that’s OK by me.

  5. Naming things like “ab-1″ or “onkeydonkey-prev” is just plain ridiculous to me. Not to mention CSS needs to be exactly in shape of site (HTML) we’re styling, not other way around. Yes, CSS is harder to write than HTML and even harder when you think about IE.

    However, it’s our job to excell in this field and those who can’t should stick with some generators or frameworks (doh…) and that’s ok with me.

    But when those people try to convince me that their lack of care is actually semantic, I don’t know where to start my reply.

    Sorry to sound bold and rude, but actually writing good class names and giving proper idetifiers *is* a skill – it helps other developers, it helps you and you won’t end up with [div class="topLeft"] laying way down on the right-bottom of site.

    I know – when I write [div class="important"] it’s no better for some blind parser then [div class="redBold-2"]. But this way we can use [strike] or [font], don’t we? Actually it seems that [b] carries more meaning (on presentation) than [span class="bold"] – but we all agreed to use semantic elements and continue that way with classes and ids.

  6. We have here a classic problem where on one hand, yes Blueprint does offer a time-saving and nifty approach to structuring a document and having a visual style applied quickly. On the other hand, we have hand-coded per site CSS where you would have to see what you want styled depending on the design.

    The Blueprint CSS framework for a simple site might have a lot of bloat, that some users might not remove, because it might not occur to them that “header-2″ or “column-4″ are useless selectors in a document that has only 2 columns and one header.

    My beef with Blueprint then is really that for it’s effectiveness, it also leaves a bad taste in that there is a lot of room for waste and generic naming, with no specific meaning for a document being given, I strive hard to make sure my code is as understandable as possible with a quick glance at my HTML document, coding the CSS should be quick as the classes and id are clearing given meaning and refactoring or coming back to it in a couple of months allows for quick edits and design tweaks.

    However, since not everyone will seem to care that much, I have to say, ultimately, to each their own.

  7. I wasn’t really concerned with your post on not using CSS frameworks as I didn’t really see the point in using Blueprint.

    However, after reading this post and taking a slightly closer look at Blueprint, I realise I have been trying to do something similar in my work recently, in putting my company’s branding guidelines into very generic classes.

    I don’t imagine a developer actually using these classes though, just cutting and pasting the relevant rules into more meaningfully named elements, hence applying semantics but still saving some time.

    I know that Blueprint contains some layout rules that would make this more complicated (my approach doesn’t have any layout rules) but couldn’t the same approach still be used?

  8. Any developer who believes class and id are best used as hooks for CSS and JavaScript are flat out wrong. If you don’t understand this then I feel sorry for your clients and/or employer who must live with your decisions.

    Spend some time looking at the CSS and the XHTML specs. The entire road map serves to sever any explicit connections by giving developers the a full range of selectors and properties to make classing with .right and .left unnecessary.

    There are still obstacles. Right now, it is nearly impossible to create markup with no presentational hooks. As much as possible those hooks, however, should be semantic. I have yet to see a CSS framework that even attempts to take the semantic issue seriously. Most are rooted around problems
    that will soon (hopefully) seem so late first decade.

    The more we try to “standardize” imperfect frameworks, the less attention we draw to the fact that we need CSS3 selectors and advanced layouts now.

  9. The issue here for me is clear – Yes, classes and IDs should be semantically written. One of the big motivators behind xhtml and css is the separation between content and presentation. With semantic markup (including your classes and IDs) you can describe in your code what each item on your page is doing and what content it holds, rather than how it looks.

    These frameworks completely disregard the separation, re-introducing presentational markup into the mix. This, in turn, leads to problems of maintainability – A year down the line, when you want to re-design the website, if you have written your code semantically, all you have to do is mess around with your css. Using a framework such as Blueprint, you need to dig around in your html markup, which really shouldnt be necessary, as you’re not looking to change your content, just the way it is presented to the user.

    As mentioned above, there is also the issue of teamworking to consider, too. Using semantic markup, a fellow team member can easily go into a page, and make an instant and intuitive link between a container element, and the content it holds. Using frameworks to build your pages, all you have to go on are presentational classes – “col span-12″ etc.

    Yes, the use of a framework can speed up inital development time, but I think that any benefits gained in the early stage will be cancelled out by the extra time and effort taken to produce updates. There is, as rightly mentioned above, the issue of people learning the tool, not the technique.

  10. I think it would be nice if people could discuss this type of topic without assuming that the opposing side was simply unskilled or ignorant. I’d rather make my own site from scratch anytime. But given the realities of the situation, I see a lot of value in frameworks.

    Zack makes a good point that the specifications should alleviate the need for some of these things. But how much progress has really been made there? Every browser on the market could implement full CSS3 and HTML5 tomorrow, but my users would still be running IE6.

  11. @pepelsbey: I’m sorry, I don’t quite follow what it is you’re trying to get across, would you mind being a bit more specific?

    @Simon Martin: I tend to agree with what you’re saying, I too take a minute to think about what it’s going to be like when I have to make an update on a current project a year from now; is it going to be easy to resume where I left off?

    @Jason: Yes I definitely agree, I try to use effective class values for exactly that reason.

    @Roman Bercot: Microformats definitely aim to make up for the shortcomings of (X)HTML, but couldn’t you view effective class names as doing that very same thing? You’re absolutely right in saying that many companies could really care less about this type of issue, it’s hard enough to convince them to work with a reputable agency as opposed to having the boss’ son whip something up in Dreamweaver over the weekend.

    @Riddle: At first, the idea of using names such as those you had mentioned didn’t make sense to me either. But if you’ve read the documentation behind the reasoning for the naming, it begins to fit together. That’s where the issue arose for me; if there is documentation to back up their use, is it okay to use such names? In the end, I do feel that using meaningful names is more beneficial in the long run.

    @Ian Gordon: You’re absolutely right; it would be very rare (and surprising) that a developer would take the time to remove all the extra bloat left over from implementing something like Blueprint, or another CSS framework. While we’re only talking about a couple k here and there, it’s just not needed. The attractiveness of something like Blueprint is absolutely the speed at which you’re able to get up and rolling on a project.

    @James: I think every developer has at least a bit of code they use to start every project. I’ve got a very basic folder structure that I use which has a few files in place to get me going, but it’s nowhere near the size and depth of something like Blueprint. Many people see Blueprint as something of a full golf bag, with each club ready to be used in whatever way you wish. While it can be a great thing for one person, it’s just a hurdle for another.

    @zack: Stating that developers using class names that you or I feel are less than ideal is wrong isn’t necessarily the way to go about it in my opinion. Many developers have been using namespaces they’ve come up with over their entire career. The names make perfect sense to them and their team and really help everyone stay on the same page. That is one of the major points going for Blueprint, it allows for each developer using it to know exactly what’s going on before comparing the markup to the style. I completely sympathize with your desire to see some CSS3 action :)

    @David Eglin: Very well written. From what you’ve said it sounds like we stand in the same spot when it comes to an issue such as this. While the Blueprint documentation can help everyone stay on the same page, meaningful identifiers can do that as well. I would like to agree with you in that a CSS framework can definitely help with initial development, but how will it fare when it comes to making significant updates later on? It will be great to read future articles detailing a comparison between working with a CSS framework and not.

    @Robert Bercot: I agree, I don’t think an assumption of a lack of skill is a point to touch upon. You’re right, the implementation of CSS3 is a long time coming, and will continue to be a tease once browsers actually implement. We’ll be dealing with the same issues when it comes to HTML5 and any new tags that come with it; how long until we can effectively use them?

    Thanks to everyone for taking the time to write these well-thought reactions. Reading the opinions of others really helps to get a better view of the overall situation, and I thank everyone for taking the time out of your day to leave your thoughts.

  12. We have to choose id’s and class names that have some meaning to our project. It will help us on development process, moreover on maintenance too.

    So I agree with you in the point that there’s semantic on CSS and we have to make a good use of it.

  13. I recently redesigned our template using Blueprint to see what the difference would be. Our current CSS file is 26KB when optimised. I managed to recreate the front page of our site in a relatively small amount of time using Blueprint’s classes, and just 20 custom classes and ids of my own (that’s 1KB of CSS + whatever Blueprint is).

    You can still have semantic classes or ids when using a framework in my opinion. Have a look at the following examples:

    #content isn’t a Blueprint id. Do you know what that holds?

    #modules and .module are mine also. Which side are they on?
    .colour-2 is mine, isn’t for semantics, serves purely for colour-scheme switching.

    I used the framework initially, then afterwards added #logo, #header, #footer, #nav, etc. Does the fact that I used a framework make my document any less semantic than yours, now that I have added semantics?

    When frameworks are used to produce non-semantic documents in the hands of the novice, who’s at fault? The framework or the novice, the tool or the user?

    I’ll leave you to make up your own minds, but I know that the next time I try to hammer two bits of wood together and the wood splits, I am not going to be throwing my hammer away.

  14. @Chris Burke: Very well written. Please don’t think that I’ve taken one side or the other when it comes to an issue like this. There are completely fantastic opinions on both side of the fence when it comes to semantics and CSS frameworks. Both sides are very compelling, and the whole issue remains quite gray for me.

    Thanks again for your well-versed reply!

  15. Mostly you’re just blatheringly self-defensive and full of crap. Pre-thought might help.

  16. @David Mills: First, I’d like to thank you for taking the time to leave a comment on the site. I’d just like to find out a bit more behind your unhappiness with what I’ve written. What caused you to feel that I was being self defensive? What makes you feel that I’m full of crap?

    It would be great if you could take a few minutes to elaborate with another comment on the site to ensure anyone who happens to read it knows more about why you feel the way you do.

By all means, contribute

Leave a comment

Powered by Fusion

This article is so meta

Published September 17th, 2007

Random article

css.php