Re: Re: Good solution for managing stylesheets

Jeff Moss
Sun, 21 Aug 2005 06:17:13 -0000

Ronny,

You raise good points. I wouldn''t consider myself an expert on the
topic
of web design, I''m looking at it from a programmers perspective.
I''d
use programmatic HTML generation to solve the problems you brought up,
heh heh.

But I''ve got to leave room for a web designer to come in and improve my
"starter design" is what I call it. I just want the interface to work,
and maybe leave my reputation in good standing by accomodating future
modifications. Your stylesheet-first design methodology sounds like it
might be the answer to a lot of my problems. Thanks for the reply.

-Jeff

Ronny Hanssen wrote:

>Sorry Jeffrey.
>
>I have to disagree about that being cool.
>
>It totally ruins all thoughts about design-elements on the pages
>actually having a common style. Also it would break the DRY. Since you
>would repeat writing the style-specs over and over again. Evidently -
>some of these html tags will get different styles, when you don''t
want
>it. Also the style-names generated will never have a chance of being
>human readable, at least not even close to what we our selves are able
>to do. Also - if the generator is to generate your css-classes the
>result is that you probably will have loads of classes defined. Lots
>more than you really needed, because it needs to cover your
"mistakes"
>where the html tags were supposed to be the same, but you forgot that
>one style attribute, leading to an extra class in the stylesheet.
>Actually - working with other people, the basic style-classes are some
>of the first ones to be defined. Not the final style, but the
>style-classes. Then we know that the app will be consistent. Like say we
>say that all article titles are to have the article_title
>style-classname. Then we use that. Now we are sure (well - never 100%
>sure of course, we are only people :), that all article-titles look the
>same. And we can redesign the look of the pages whenever we like to
>without having to dig into each html tag in the project. Not to mention
>the happiness for clients that have the application installed and who
>also wants to do customizing. They have a clear stylesheet to sit down
>and edit where one can actually understand what''s what. I have even
>gotten used to adding comments before the classes in the stylesheets to
>better explain their effects and purpose. I know that it adds to the
>initial download, it''s just a sacrifice that I''ve chosen
to live with.
>It''s also a document which is cached so it''s really only
the first hit
>that has extra fingerprint. The customer satisfaction (and also
>developer ease) is well worth it. Anyways it is still possible to use a
>rake task or similar to cleanse them before release, but leave a second
>copy behind for documentation perhaps. Hm... Maybe in a separate file,
>like mystyles.css and mystyles.css.txt. And have the rake task actually
>move comments to the txt file and css to the css-file. Just for
>reference. The latter part was an idea that popped up right now, I might
>look into that later...
>
>I recently spent a lot of hours on a project, moving html style
>attributes into css, and cleaning up the css and giving the classes
>meaningful names. The old names were most of them like this:
>.red_bold_with_border
>
>Which are good for reading in the html file how it looks. This works
>until you decide to change the color-definition within the class to
>yellow. So what do you do now? Change the name to
>yellow_bold_with_border? Lessons I had to give on this subject was to
>think of their html output as objects/blocks, and decide what they where
>or what they contained, *not how they looked*. They finally got it, and
>code produced now is much better and the output looks coherent at a lot
>earlier stage.
>
>So, sorry Jeffrey. I really, really cannot follow you on that
"cool" thing.
>
>Regards,
>
>
>Jeffrey Moss wrote:
>
>
>>I don''t see how this makes maintenance any easier. You still
are
>>maintaining multiple stylesheets, it''s just you don''t
include them in
>>the templates you include them in your global stylesheet, which IMO is a
>>bigger pain, and doesn''t afford you as much flexibility.
Separating IE
>>specific styles into their own stylesheet still requires that you
>>dynamically output the stylesheet name.
>>
>>I think Michael was just talking about a speedy user experience, where
>>he does have a valid point, and I''ve thought about that before,
I just
>>don''t think it makes much difference usually, either way you go
has
>>tradeoffs. I''m more concerned with where I''m doing all
my editing, so
>>ideally i would just be able to embed the style in the HTML elements and
>>have it all extracted into an optimal set of stylesheets by factoring
>>the commonalities on the individual attribute level. THAT would be cool.
>>HTMLTidy has a feature that''s supposed to do this but last time
I tried
>>it, a few months ago, it savaged my pages.
>>
>>-Jeff
>>
>>
>_______________________________________________
>Rails mailing list
>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>
>