Re: Re: Good solution for managing stylesheets

Ronny Hanssen
Sun, 21 Aug 2005 15:04:59 -0000

Thanks. I understand :)

I think it''s good that you liked the "stylesheet-first" part,
because it
helps you focus on programming, not on designing. The initial stylesheet
may only have empty class declarations, but it is still a good start. I
guess a handful of styles can take you far.

Regards,
Ronny

Jeff Moss wrote:
> 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
>>
>>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

--
------------------------------------------------------------------------
/*Ronny Hanssen*/