The ultimate goal of me re-factoring my website is to write “smarter” HTML, CSS, and PHP, and cut out a lot of the duplicate, triplicate, quadruplic code that I have amassed over the past year while focusing more on cranking out pages and less on “re-usability”…
Use classes instead. So you can group all of the common features in one class (say “common”) and then anything that’s unique would have its own class (e.g. “special”). So your div would look like this:
The only thing I haven’t tested is how the browser versions’ (where supported) document.getElementsByClassName() handle elements with multiple classes. Hopefully they do but as a last resort you can write your own customised js version to handle the situation
And I can use multiple CSS classes in one tag “with full confidence”, as Ralph says? (I’m certain that I had seen where that is buggy?! :-/ Or am I thinking of something like “class1+class2” ??)
Debbie
P.S. Ralph, it sounds like you are recommending an incontinence product…
can you post a link to where it was said to be buggy? It works fine for me and I often use multiple classes the way Ralph described without any probs at all.
You are probably thinking of CSS styles that link those classes together, such as
.common.special { ... }
which I believe can be buggy in IE6. But that’s irrelevant now, IMHO. A rule like that means “only apply the following styles when both classes are present on the element”. But that’s not how you are using them here anyway.
[ot]
it sounds like you are recommending an incontinence product…
Paul O’Brien is so versatile with CSS that you never know how many purposes he could adapt it to. :)[/ot]
The point being made in the other thread is not to use class names that describe the appearance like “.yellow”. If you decide to change that color later, it will look rather silly and will get quite confusing. There’s no actual rule for all this. It’s just a matter of being practical. If those divs are likely to maintain their role in future, it might be quite fine to use special styles like
.events, .featured, .top10 etc.
Just try to design them so that they are meaningful even if their appearance were to change in future.
It’s up to you, really. Just think ahead, though, to the day (not necessarily very far away) when somebody says to you—“Ew, rounded corners are so last decade”, and so you rush to change your styles to square corners. Then you’ll have a class across your pages called “roundedCorners” for elements with square corners. Then you are told that the yellow looks hideous, so you rush to change your .yellowBackground to #f7f7f7. How silly is that class name going to look then? You will be tempted to open every page where it appears and change it manually—which defeats the whole purpose of CSS.
.headerBar seems more reasonable to me, as it describes a function rather than an appearance, and is more likely to stand the test of time. You can change the appearance and it will still be a headerBar.
It depends on the content that that the above refers to. If for example each of those different colours refers to perhaps an alert box, a warning box, a notification box, an error box etc… then you already have good names to use for them (i.e. .alert, .warning, .notification, .error etc).
If on the other hand you have 10 boxes that hold the same or similar content and you have just styled them differently for a visual effect then a class structure such as effect1, effect2, effect 3 would also be ok because the content meaning isn’t changing beacuse it’s just a visual effect (but funnily enough still makes it harder to debug as the names mean nothing that you can really refer to and names such as hot, warm, cold etc may be better). Most of the time though elements are styled differently for a reason and not just a visual effect so you really need to use the meaningful class name.
It’s also important to know when to stop as the following would be a a nightmare to maintain.
There’s a trade off between efficiency and maintainability and the code above is getting very close to inline styling and the old attribute way of inline styling (font and color tags etc). Sometimes just having a few extra bytes in the css is better than complicating the code so that no one can ever read it again. (Just try to debug a wordpress menu for a bad example). Two or three classes at the most would be the limit but just don’t overdo it.