Matt Kruse wrote:
While developing an internal IE6-only webapp, a discussion started about the
'best' way to apply classes to data tables across multiple pages. The two
arguments were:
1. Apply a single class to each table. That class (possibly in combination
with other classes on child elements) controls every part of the table -
layout, colors, fonts, etc. Example: class="data"
2. Apply multiple classes to each table. Possibly one for layout, one for
colors, one for effects, etc. Example: class="compact dark grid dropshadow"
So this is mostly a question of opinion - When do you suggest using one
class vs. multiple classes and why? Is there a general rule that can be
quantified, or does it depend on the situation?
This is a similar to a topic that goes around in object-oriented
programming circles (e.g. C++): single inheritance vs. multiple
inheritance. It is stretching it a bit to say it is the same as single
class vs. multiple classes, but not far off either.
The general consensus is that multiple inheritance is to be avoided; the
word "evil" often arose in discussions. It creates non-linear relations
that are hard to track as the code ages, specifically the "unintended
consequences" problem, aka: collateral damage, ripple effect,
interdependence, high cohesion.
Multiple inheritance does not scale well and is hard to maintain. The
same can be said for multiple classes. Building a bunch of Lego styles may
seem efficient at first. It becomes a mess after a while.
Consider what happens when you change the ruleset for "dropshadow."
Wherever dropshadow is used, its appearance changes. When used in multiple
class style, zero or more unrelated parts of the site change appearance as
well. This may or may not be desirable.
Multiple classes can be useful when used in a focused, limited manner.
It is not a generally useful method.
--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)