Errol writes in:
What’s your thoughts on a situation where you’ve started
naming classes and then halfway through you realize that
you need the same class but the naming isn’t semantic.Do you create a duplicate class, rename the existing one
to something more general, or something else?For example:
I’ll have a #modules_list_footer but now I need the same thing
for articles, so I could just use modules but it
should be “#articles_list_footer”.
We’ve all been there.
When you first coded the site, it was beautifully semantic. Everything was perfectly named and made sense to all. Then the site grew, new areas were added, new layouts were needed, stylesheets started to bloat. Your “#articles_list_footer” made perfect sense, but now you need to use that same footer for a new area that really isn’t and article. It’s tempting to just use that ID anyway, because it will work just fine. But that starts you down a road of deteriorating semantics… What’s a poor coder to do? These are the options I see, in order from best to worst.
1. Rename!
I’m taking a stand here and saying your first option should be to rename the offending ID or Class name. It might be a pain. It might involve updating a lot of pages and being nasty grunt work, but… it’s the right thing to do.
2. Make a New Name
Situations may arise where it is just way out of the question to rename. Thousands of pages… potentially missing pages and causing layout issues… In this case I am suggesting that you add a new name in addition to to original now-outdated name. In Errol’s case, just add a new ID name that makes more sense generically:
#modules_list_footer, #list_footer {
...
/* Note: #modules_list_footer is deprecated, use #list_footer */
}
Since they will be sharing the same attributes exactly, you’ll be all set to use the new name. Then make a note in your CSS that the old name is deprecated for future developers.
3. Use the Old Name
If you aren’t talking about just a single new name that you need, but lots and lots of names, the CSS bloat that #2 might cause you might be just too much. You aren’t going to be suffocating any kittens by just giving up and using that old name. At least you have learned your lesson and you know what you can do better next time which puts you ahead of 80% of other web developers anyway. Perhaps make a note in your CSS about the naming problem, and the next site you code, you can call it #list_footer to begin with!
Of course, these are just my thoughts. I’m sure plenty of you have your own methods for dealing with this. Anybody have other ways of handling this?
Use the cascade:
<body id="article">
Then, in your CSS:
#footer {} /* general rules */
#article #footer {} /* specific rules */
I agree with the suggestion to use the cascade – with an OOP background myself, cascades are both familiar and the easiest for me to read.
However, for the specific problem Errol presented, I agree with Chris’s #1 solution. Find/Replace is only getting better in a lot of editors and IDEs, and I think this situation calls for putting it to the test.
Good luck, Errol! And thanks to Chris for posing yet another interesting discussion in code paradigm!
The point is to code so that you don’t run into these problems. For instance, if you nest elements correctly and define structure-based elements with ID’s — and dynamic, repeating, or modular elements with classes.
Quick example:
main -> div.inner -> p
sidebar -> div.inner -> ul
footer -> div.inner -> p
main, #sidebar, and #footer include the CSS for the structure (width, height, etc), and div.inner is declared and applied to each section, maybe to show a different background color or image and positioned using padding. Also, declaring a general div.inner and #main div.inner (specificity) can produce different effects! Very versatile!
This is one of the reasons I use dreamweaver as you can link all your pages together, so ctrl+F then ‘replace all’ will change all instances on your website of that unsemantic name
Answer #1, renaming selectors, is a hassle and why should it end up better this second time than the first? Unless the project is the developer’s first, or the project is about to be abandoned from further refactoring. And, unless a similiar solution to comment #4 is available (although if it were available, the question posed would not be a question since this should be applied with in 5 minutes).
Answer #2 is highly temporary and would only suffice for short term solutions. Also, it increases file size of both CSS and HTML.
Answer #3 is probably the most time effecient way to go, together with a design guide or equivalent available to everybody taking part of the CSS development.
Why fix something that isn’t broken in the first place.
Dang, I’ve always cheated and done a mass find/replace. LOL.
I’ve replaced classes in WP posts by using a search and replace in the mySQL database. It’s a bit scary, but if you back up your database first then you can always just revert. This worked well for me, replacing classes and also image addresses when I moved them from Photobucket to my server.