[thelist] your opinion solicited on coding specs I requested from contractor

Sam-I-Am sam at sam-i-am.com
Mon Oct 22 16:44:17 CDT 2001

> Except, if you are using the same look, for 20 different purposes, you end up with
> a very confusing style sheet. Also, if you want to repurpose the style sheet for
> another section of the site, or a site with the same look, you have to totally
> re-create the style sheet, and you've got to keep track of all of the different
> uses.
And that's where the trouble starts. 
You are right of course. I've seen it where someone wants to use certain
style properties and the only classes available are things like
.subheader {}, then inevitably you'll  get someone who'll give you <a
href="" class="subheader">, rather than add the new class and usage to
the document head or linked css. 
In an ideal world you would have been able to anticipate all needs and
uses when originally authoring the style sheet, but needs change. 

> Believe me it became frustrating to
> use "logical" (they didn't stay logical for long) names for a description of a
> style. 

I can't deny this. I want it not to be true. My approach comes out of
having to revisit pages, and sites and implement changing look and feel.
Often throughout a prototyping and design evolution process. But out in
the "real" world the needs are a little different... perhaps there's a
middle ground, or maybe delivery of a template set and css involves
mapping the structural, logical classnames to more descriptive ones for
"consumer" use.

> Oh yah and we couldn't use IDs because often the programmers used them for their
> magical programming stuff that they do... at least that's what we were told.  ;-)

ah.. DOM-ish stuff. That's fair enough, and I've come across the same
thing - it makes me think there ought to be a way to distinquish
attributes intended for client-side rendering, from those intended for
server-side parsing and use.. Sooner or later the 2 are bound to clash.
But anyway..


More information about the thelist mailing list