Seeking Polymorphic CSS Class?!

Okay all of you CSS gurus, I could use some help coming up with a more advanced approach to my CSS classes.

Specifically, I would like to create a “polymorphic CSS class” that can easily be expanded and help reduce redundancy in my style-sheet!

In my website layout, I have a need for lots of “boxes”.

For example, I might have an “Upcoming Events box”, a “Special Offers box”, a “Featured Article box”, a “Top 10 List box”, and so on.

Each of these example “boxes” would share common things, like:

[INDENT]- 1px gray border

  • 20 px top/bottom margin
  • 10 px padding[/INDENT]

However, they could each be different with things like:

[INDENT]- background-colors

  • font-color
  • reversed header?
  • etc.[/INDENT]

Currently I just created a separate “box” for each need, for example:

[INDENT]#box_Events{}
#box_Featured()
#box_Top10{}
#box_Specials{}
#box_Articles{}
#box_OnSale{}
[/INDENT]

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”… :frowning: :frowning: :frowning:

Wisdom is welcomed!!

Debbie

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:

<div class="common special"> ... </div>

you realize you can assign more than one class to a tag, right?

curses, sniped again :wink:

Are you referring to what Ralph posted?

<div class="common special"> ... </div>

I thought that using more than one class in double quotes was not supported very well and therefore unpredictable and buggy…

Debbie

No, it’s standard practice. Use it with full confidence. :slight_smile:

Not in my experience.

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

i wasn’t when i wrote it (obviously), but yeah, that’s the idea – one class for the common stuff, and others for the unique nuances

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… :lol:

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]

Yes, that seems to be what I was thinking of earlier.

So, back to your recommendation, can you elaborate some more of how you use this strategy make your CSS more powerful and yet simpler?

Maybe some examples?

And is there any number of classes you’d want to use in a given tag? (I assume you don’t add 10-20?!)

I like your idea, but am still cautious, because of one of myearlier threads here: Best way to style Inline Text?

In that thread, you and several others discouraged me from doing things like

.redBoldText{}

because it has no semantic value, was getting too granular, and could backfire on me if things changed.

If I take your and r937’s advice and did something like this…


<div class="box header yellow">
	<p>Some text goes here…</p>
</div>

…then am I not sorta doing that same thing?

I mean I like the “component architecture” aspect of coding CSS like that, but one could also argue that it is a bad strategy.

Follow me? :-/

Debbie

Your own example here is perfect for this.

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.

Okay, I see what you are saying, and don’t disagree about classes like:

.events{}
.featured{}
.top10{}

But what about “specific” classes that take those “general” classes and modify them like:

.headerBar{}
.yellowBackground{}
.roundedCorners{}

Is it a “good thing” or a “bad thing” to break out physical characteristics - even if repeatable - like the example above?

And if that is okay, then where would you draw the line as far as “How many classes should describe on tag?”

Debbie

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.

So here are some of the “boxes” that I am envisioning…

1.) White Background, 1px Gray Border

2.) Yellow Background, 1px Gray Border

3.) Light Blue Background, 1px Gray Border

4.) White Background, 1px Gray Border, Gray-Shaded Header with White Bold Text

5.) Yellow Background, 1px Gray Border, Gray-Shaded Header with White Bold Text

6.) Light Blue Background, 1px Gray Border, Gray-Shaded Header with White Bold Text

So what would be some “good” classes per your warnings above?

Maybe this…


.box{
	background-color: #FFF;
	border: 1px solid #AAA;
}

.special{
	background-color: #FFFFCC;
}

.cool{
	background-color: #D6F5FF;
}

.headerBar{
	padding: 0.3em 1em;
	font-size: 2em;
	font-weight: bold;
	color: #FFF;
	background-color: #AAA;
}

Or possibly this would be even better for the last one…


.headerBar h2{
	padding: 0.3em 1em;
	font-size: 2em;
	font-weight: bold;
	color: #FFF;
	background-color: #AAA;
}

What do you think?

Is that any better?

Debbie

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.

<div class=“error-box error-box-highlight error-box-subbox error-box-style2 error-box-confrimation”>

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.