Sent by Adam Kuehn on 29 September 2004 20:08
Jeff Ward wrote:
> >As Zoe mentioned, don't be a classaholic. Use contextual selectors
>>and semantic groupings wherever you can. It streamlines things a lot
>>when you have useful page divisions with IDs on them so you can use
>>constructs like
>
>>#content p a { /*rules*/}
>
>>rather than the more ambiguous
>
> >a.contentlink { /*rules*/ }
>
>I actually have a question about this. As an ASP.NET programmer, I find
>using the content selectors neigh impossible (id is used in ASP.NET to
>identify controls, and each one must be unique). I therefore have been
>using classes of objects for both ASP compatibility and because, for me,
>using id suggests a one and only one relationship, whereas the entire reason
>for me to use CSS was to generalize the look and feel of the page.
ID does indeed mean a one-and-only-one relationship. The only
technical differences between IDs and classes in CSS is 1) IDs must
be unique and classes don't, and 2) because of that, IDs have greater
specificity in the cascade. Remember that in (X)HTML, and therefore
in CSS, uniqueness is evaluated on a page-by-page basis.
Accordingly, IDs can still be used to generalize the look and feel of
a site. I typically use markup along these lines:
<body>
<div id="header">Header Stuff</div>
<div id="nav">Navigation, usually in a list</div>
<div id="offers">Information in a sidebar</div>
<div id="content">The main guts of the page</div>
<div id="footer">copyright and footer things</div>
</body>
A single linked stylesheet served site-wide will apply to all those
groupings on each page.
>So my question is about using classes as semantic groupings, as opposed to
>IDs. In my page instead of Adam's example of:
>#content p a { /* rules */ }
>
>I would use something like:
>.Content p a { /* rules */ }
>
>Is this worse for any reason?
No. That have different weights in the cascade, but that usually
isn't a problem if you are careful about writing your rules.
> I also have generalized classes, so I can
>have things like:
>.TableType1 { /* rules */ }
> .TableType1 .Header { /* rules */ }
>
>.TableType2 { /* rules */ }
> .TableType2 .Header { /* rules */ }
>
>So that changing the look of a table only requires I change the table's
>class, and not the rows surrounding it. Again, is this bad CSS programming?
>Is it better or worse? Is it even standards compliant!?
In reverse order, it is standards compliant (although be careful with
case, since classes and IDs are case-sensitive in XHTML); better or
worse depends on what you are trying to do, but this is probably
fine; it isn't bad programming, but I'll bet you can do the same
thing with less code.
In your example, why does the class .Header exist? Why not just use
..TableTypeX th { /*rules*/ }? What does the class add?
Classaholics typically do this in the extreme:
a.navlink { /*rules including fonts, text-decoration, colors, etc.*/ }
a.contentlink { /*rules including fonts, text-decoration, colors, etc.*/ }
<body>
stuff<a class="navlink">navlink1</a><a
class="navlink">navlink2</a>...<a class="navlink">navlinkN</a>
more stuff
<a class="contentlink"> contentlink1 </a> stuff <a
class="contentlink"> contentlink2 </a> stuff ... <a
class="contentlink"> contentlinkN </a>
</body>
With the markup I showed earlier, with discreet divs for each page
section, I would use something like:
a { /* general rules for all links - e.g. font & text-decoration */ }
#nav a { /* override rules like color, or add rules not previously
declared - e.g. font-weight */}
In my version, both the CSS and the markup are cleaner and easier to
manage. Both methods will work, so neither is necessarily good or
bad. I just prefer to make it as easy to see as possible.
HTH,
--
-Adam Kuehn
______________________________________________________________________
css-discuss [EMAIL-REMOVED]]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
