Articles
RSS FeedNovember 27, 2007
Semantic class names - get real
This kind of blog post pisses me off. This is written by the kind of people that just read Trancending CSS and feel enlightened now.
You’re throwing around the wrong examples. Class names on micro level mean nothing. If a table cell has a class="marked", I’ll inspect it with Firebug to see what this class does. I don’t care if the class is called left, or green. At least these classes gives me a decent hint what the class does.
Semantic class and id naming only makes sense in the bigger picture. If your containing div is called container, or page, if your content div is called content, your sidebar blocks called sidebar, I immediately know what’s going on. I get what you’re trying to say with those class names - and when I need to know the details, I’ll investigate. No matter how semantic your class name is, the only person that’s going to immediately get what it means is you.
Each minute you spend making up semantic class names is a minute less you can spend on doing something meaningful to improve the website you’re working on. Like labelling your forms, or optimizing file sizes.
What is so hard in making up semantic class names anyway Wolf? I don’t see how you would gain any noticeable extra time?
You mention the bigger picture, I’ll give you one. What of you give an element the class “left” to indicate that you position a menu at the left side of the screen. When viewing the page in a normal web browser, indeed it is positioned left.
Requirements change, and the page should suddenly be accessible to other (mobile) device with less screen estate. Let’s say that it is now more convenient to position it above the content (i.e. faster access to navigation and more space (width) for real content). Suddenly that class name makes no sense at all. Was it so hard to come up with another name in the first place?
“At least these classes gives me a decent hint what the class does.”
Sure, they might make sense in _one_ scenario, but not in _all_ scenarios.
Presentation is linked to meaningful elements in your page, so give them meaningful css names too. I don’t see any point in using names link “shifted”, “left”, “large”, “redtext”, … when properly defining your css (and properly structuring your xhtml) you have plenty of flexibility to define it in other regions.
Better even, instead of giving elements an extra class, use css selector specificity to its limits instead of adding extra class attributes to your elements, who’s only intend is to specify specific repeated layout behavior. We might as well resort back to the attribute then.
Or do I fail to get your point? Feel free to comment :)
November 27th, 2007 at 12:14 ∞errata:
November 27th, 2007 at 12:16 ∞* link = like
* we might as well … to the “font” attribute … (HTML got filtered out)
Ok:
Scenario 1:
Client gives you mockup.
For no apparent reason, some table cells have left aligned text, some table cells have center aligned text, some table cells have a different font-weight.
Task: find decent class names. Impossible - because there was no meaning in the first place. If there’s no meaning, one can’t make up one.
Scenario 2:
You’re designing a product page. Each product has a specific color. Each heading has to have the same color as the product’s color.
How are you going to name your elements now?
If specs change, there’s always “find and replace within project”.
November 27th, 2007 at 12:26 ∞I’m with Lode (although it’s font tag ;-)).
Scenario 1: what about the content of the table cells? If the first is the about blurb, give it the id or class “about”. If the styling stays the same no matter what the content is, call it “first”.
Scenario 2: even simpler: use the name of the product.
Find and replace isn’t that easy if you’re using multiple selectors (unless you’ve got a hang of regular expressions).
November 27th, 2007 at 12:38 ∞Scenario 1: The content is not always defined.
Scenario 2: Products are pulled from a database with 20+ products.
All these theories are nice and well if you’re creating your own little site on the web, but in production work, so much of what is being said in the “CSS” community is just useless talking.
November 27th, 2007 at 12:48 ∞Kevin: Indeed, of course that should have been tag *grabs a coffee* :)
Wolf: I feel that the examples you give are the (rare) exceptions to the rule. The article you referred to does a good job at explaining a general rule of thumb. I am not going to say that you can’t make any exceptions. I am guilty of that too.
Most of the time however, most parts of a layout adhere to a certain consistency enforced by the designer (at least, I hope that it is the case), and as such this rule can be happily applied.
November 27th, 2007 at 1:00 ∞If inconsistencies do exist, one should argue and examine if they are really needed (do they express different meaning? is it a purely visual thing?).
Either way, before we add a new classname, we should always resort to the use of css selectors and semantic xhtml to address the problem, most of the time this will allow us to specify those ‘quircks’ without introducing new xhtml elements or class/id attributes.
If the visual change expresses meaning, that meaning can be captured in a suitable word/expression.
If not, it should not necessarily eliminate the possibility that we might get to the solution by using very specific selectors. I’d still prefer those to adding a new classname.
When you’re really in a dead ally, I’d go with it too, but not without consulting the previous steps.
I can understand how you are often faced with inconsistencies throughout mockups/design/layouts. Part of your job as a designer is to address these issues by pointing them out to your client, part of it is to resolve them when there is no other option.
There is no clear line that can be drawn, but don’t I think you should discard the article as being totally bullshit (not that you stated it that bold). As a general rule of thumb it is a very good thing.
Claiming that extra time performance was the thing that god me writing these comments in the first place, as I found that to be a bit silly.
Scenario 1: Tables represent tabular data, this implies that each row and each column has meaning and by consequence, each cell has too. If not, than you are using the wrong element. Any visual inconsistency should therefor also be backed by a reason. If not, I think you’re not doing good job, both at the interface level and at the information architecture level. But than again, I am a strong believer that your content and information should come first. Presentation second. But I do see how there can be exceptions to the rule.
Scenario 2: it sure ain’t difficult to generate unique id’s (and optionally generate the associated CSS)… Still strikes me as a very rare case and does not invalidate the general rule of thumb.
November 27th, 2007 at 1:09 ∞Hi, Wolf. I would like to mention, that I am a “kind of people” who have never read a single HTML or CSS book, never. I have self thought both the HTML and CSS before any of the CSS books were available :) (even long before the one you mention)
All my reasoning comes from real life projects and I’m absolutely not advocating pure “semantic” CSS identifiers. I was trying to explain the possible balance between pure layout classes (where .left is OK) and content classes where .left is bad in the long run.
And your idea that “semantic class and id naming only makes sense in the bigger picture” support this very point. At the same time I also agree with everything that Lode said.
November 27th, 2007 at 1:37 ∞Agree on both I must say … take Wolf’s second example: according to which segment a product belongs the color should change of all links, strongs, etc.
One could argue to “just give the div a class set to name of the segment“. True. Correct. But … your gaze is now focused on the product, not the whole concept. And that’s when things happen just outside your range of vision: in the example mentioned (FYI: I’m also working on that site referred in between Wolf’s lines) all of the sudden certain pages have a color indication too.
Where a
<div id="product" class="segmentidentifier">makes sense,<div id="page" class="segmentidentifier">makes no sense at all, as a page is not linked to a segment, but to a color. Therefore we (Wolf) has chosen to use the colorname as a class on the pages and then backdrop (viz. afterwards) those classnames on the products.I think the above explains why Wolf chose those names … it all merely depends from what your starting point is.
November 27th, 2007 at 7:26 ∞* depends on :blush:
November 27th, 2007 at 7:27 ∞Not sure if I totally get the example based on your explanation. But I am sure you guys know what you’re doing. No doubt :)
November 27th, 2007 at 8:22 ∞@ Lode: here’s a more extended explanation ;)
Imagine this set of products: 1GB Ram, 512 MB Ram, 256 MB Ram, 1TB HDD, 500GB HDD, 250GB HDD. Those products can all be placed into a producttype (cfr. the segment mentioned above): Memory or Hard disk.
Now, the class names could then be: memory and harddisk (viz.
<div id="product" class="memory">and<div id="product" class="harddisk">) which seems logic, and semantically is correct.Above that you must know that the client wants the borders and links for all memory products to be pink, and lime for the hard disks –> The selectors above would merely change the colors used (the id selector
productwould define placement/positioning).But, in the designs of the regular content-pages (viz. an info page, a contact page, etc.) you suddenly see that they also want the borders & links to be pink or lime. One could recycle the classnames above as classnames, yet imo it would be odd to use
<div id="page" class="memory">and/or<div id="page" class="harddisk">as those pages have nothing to do with either memory or a hard disk. On the pages, it would be more logic to use<div id="page" class="lime">and/or<div id="page" class="pink">.Knowing this it’s better to use pink/lime on the products too in my/our opinion, as you’ve already defined the selector for the color-based classnames and because of the fact that a classname
pinkmakes sense on both divs (one having the idpage, the other having the idproduct) whereas a classnamememorywould not.Hoping this explains it a bit better ;)
November 28th, 2007 at 11:24 ∞Funny to see how much time you guys have on your hands to discuss things that have been discussed a million times before all over the web ;)
November 28th, 2007 at 11:44 ∞[...] Blue Flavors’ Jeff Croft demystifies the idea that HTML and CSS allow for a complete separation of structure and presentation in this blogpost. When you redesign a website, you always go back to the XHTML. Non-semantic classnames don’t hurt. [...]
June 9th, 2008 at 12:34 ∞