How to deal with the need to change CSS class names

Question

I'm looking for people's strategies for dealing with the inevitable need to change or otherwise adapt a CSS class to accommodate new HTML elements. I find myself in this situation fairly often so I'm hoping other people share my pain and can advise here.

Imagine you have a table of products with the nice semantic class name products. This is styled appropriately in your stylesheet. A few months down the line, your boss asks you to create a staff list on the site, "styled exactly the same as the products list".

This immediately raises an important question: what to call the new staff table. The only options I can think of are:

• Give it the class name products as well. This is the quickest solution but ruins the semantics. The naming makes little sense especially to future developers.
• Change the class name to something that can encompass both products and staff listings. This would negate the utility of separation of markup from style as the HTML would need changing. Also, I can't think of a single non-presentational class name that could conceivably apply to a products and a staff list.
• Introduce a new class name and edit the CSS file such that .products { ... } becomes .products, .staff { ... } and .products thead th.number { font-weight: bold } becomes .products thead th.number, .staff thead th.number { font-weight: bold }, etc. Another ugly solution which will only get more complicated as time goes by.

What's the best course of action to take here?

N.B. I'm sure this problem is easily solved using frameworks like LESS (I've not used it personally) but this solution strikes me more as a 'cover-up' than an actual remedy.

Answer 1

There are basically two schools of thought here.

1) Style that follows markup 2) Markup that follows style.

You have to figure out which one you want to do, and try to stick to one or the other. if you mix too much then it's pointless and you just have a huge mess.

In the first, you have a set markup that doesn't change. You figure out style to make it look the way you want. This is in the vein of css zen garden. It requires that your markup be extremely semantic. The drawback is that you often have a lot of duplicate styles because it's not always possible to style cleanly when using this method.

In the second, you create a lot of common styles, then adapt your markup to fit the styles. For instance, you might have a classes of "float", "thinBorder", "bold" then apply those styles to your markup. The drawback here is that if your style needs change then you have to change the HTML (or make bold not be bold, or some such). The positive is that your CSS is much more clean and maintainable.

It sucks, but you have to make tradeoffs.

Answer 2

Introducing individual class name for new type of content would probably be most right solution. But unfortunately current CSS syntax is far from perfect and thus forces us to be too verbose in our CSS by listing full selectors one by one.

So in practice, most maintainable solution is usually to try to find a common name for different things styled identically.

Answer 3

I would go with first option, to have class products with this block.... or maybe like class="products staff"

This way I won't be having duplicate styles(even from future aspects,when code/styles might change a lot), and any specific styles for products can be done like this by new class(or by another way of using parent class in styles to give more specificity of styles).

Yes, product class word doesn't makes much sense here, but again even for future developers, it still means you are using styles of staff class,not related to logic...

But still yes, if possible to modify markup at ease from product to some other word , I would do it.. but not as such a major requirement in these case...

Answer 4

Hmm...

Basically the root the problem is that your original thought of creating the first style class (.products) was too narrowly named. It is not always possible to know that you will need to reuse a significant portion of a CSS definition at a later point but based on your question it seems like you are in that line of business.

The core CSS framework does not have the way to say 'make my new style (.staff) be the same as another style (.products) with these overrides'

But I believe that the LESS framework does give you the ability to define a class (.coolTable) with all the properties and re-use these properties in multiple other class defintions (.products and .staff) quickly.

The LESS framework is not a 'cover-up' as much as an extension to the capabilities of CSS.

Answer 5

I am going with first option because if everything is same & there just a change in content. So, is better to use the previous products class for staff also & Your can separately define your staff panel with the help of comment <-- staff plan-->inside the HTML page.

Answer 6

This is one of the things I really dislike about CSS. With all the powerful languages at our disposal, this one just seems crippled from the get-go to handle very common scenarios like yours. I too struggle with this all the time and end up either copying all the .product-related class defs to my new one or adding my new one to the .product ones. They could be pulled out later.

I need to study up on the pre-processors too because what I would love to do is something OOP-y - define b 'base class' that both .product and .mynewone inherit from and go from there.

But #3 is your best bet IMO.

Answer 7

If you had to put your style of the table into a few words, what would it be? I try and use that to name styles that I am gunna use in more then one place. Then I have an idea of what it will look like if I use the class.

Example:

.table-striped{}

Answer 8

How about Option 4:

Make a copy "products" as "staff" and continue to work on them separately as time goes on.