tags:

views:

50

answers:

2

Hi all,

Which is better practice?

.listing { some attributes:some values;}

applied to multiple locations (e.g. search results, category listing)

or

.search-list,
.category-list,
.other-list { some attributes:some values;}

It seems to me that the second option provides more flexibility for future changes to style without changing (x)html and also easier maintenance due to knowing exactly where the rules are applied, but needs more bandwidth to download and browser processing power to parse.

Interested in your thoughts.

Thanks, Jonathan

+2  A: 

Use context, as implemented using child selectors, (modified based on your comment below). This makes it clear what attributes are part of a general list and what attributes are specific to a search-list.

.list li { default attributes: default values }
#search-list li { attributes specific to search listings: some values; }

with markup

<ul id="search-list" class="list">
  <li>...

I've recently been working with some top designers. They talk negatively about markup that has "div-itis" or "class-itis" (they would skip the list class above and style ul). To counter this, they use ids and native tags like li, h5, etc within. Since it's a PITA to clear default values, they define only a few defaults and use contextual selectors for the rest. They use multiple class names when they need them. They also tend to use compass or less because these environments allow contextual selectors and mix-ins.

Rob
I like that approach to use generic elements that are semantically correct and combine the generic and specific with overrides, my concern with your example is adding extra markup with extra divs. how about `<ul id="search-list">` instead?
Jonathan Day
@Jonathan: that's better. exactly what I notice the designer's doing. they really restrict the div's to semantically correct uses - identifying sections of the page that are logically grouped. i'm trying to break the habit and fell right back into it!
Rob
+1  A: 

You could add

.elephant-list,
.aardvark-list,
.platypus-list,

in anticipation of future expansion also, but there comes a point when you cross from flexible to absurd. There is no reason to code special names for classes that you have no reason to expect will need to differ.

Should you find that they need to differ in the future, add them. Also from an aesthetic view having .listing divisions share the same styles is a Good Thing.

msw
Completely agree on having all "listings" look the same, hence the chaining them together with a common style. I'm not suggesting to add imaginary listing types for the sake of it, but if I know that there are three types of listing (search, category, other) that currently exist, then is there a downside to selecting them specifically and setting a common style?
Jonathan Day
It may give your stylist ideas of things to change that probably shouldn't be without compelling reason; it hides real commonalities behind different names which will cause a future reader (including you) the burden of having to recall that X and Y are actually equivalent. It adds lexical complexity to code that is pretty ill-structured to begin with. I don't think it deadly, just inadvisable.
msw