this is exactly why we use serverside scripts along with a config file
to define some base declarations such as colors.
then we can change the color in one place only, using the below example
#results .fn { font-size: 0.86em; color #739EA8; }
#results .tel { font-size: 0.86em; color #333333; }
#results .adr { font-size: 0.73em; color #739EA8; }
would become something like
#results .fn { font-size: 0.86em; color: <?php echo $styles->color->color1; ?>;
}
#results .tel { font-size: 0.86em; color: <?php echo $styles->color->color2;
?>; }
#results .adr { font-size: 0.73em; color: <?php echo $styles->color->color1;
?>; }
in our config file, we have
color.color1 = #739EA8;
color.color2 = #333333;
allows easy update of almost everything, much easier to maintain as well.
Adam
Korny Sietsma wrote:
I tend to agree about SASS, however I'm not sure you can really avoid
repetition in css. (ok, "endlessly" is an overstatement!)
Sure, where possible we'll reuse classes, but there are several places
where this would be hard, or would make our css messier.
For example, if I have a name field coloured #739EA8 and font size
0.86em, and a phonenumber field coloured #333333 but also font size
0.86em, and a address coloured #739EA8 but 0.73em; I could try to
define some base class with font-color #739EA8, and a second one with
font-color #333333, and a third base class with font size 0.86em, and
a fourth base class with font size 0.73em - and then mix those classes
together as needed - but it doesn't feel like semantic markup to me!
Instead, I have
#results .fn { font-size: 0.86em; color #739EA8; }
#results .tel { font-size: 0.86em; color #333333; }
#results .adr { font-size: 0.73em; color #739EA8; }
... and when the designers say they want to change a font size, or a
colour, we have to change it all over the place. It's not a vast
effort, but it would make the code more readable and more maintainable
if we could define the sizes and colours once. Maybe it's just having
had the "don't repeat yourself" mantra hammered into our heads too
often :)
(Incidentally, as to your other points, most of these tools like SASS
will generate standard readable css files at deployment time - I agree
we don't want css to be generated at run-time!)
- Korny
On Mon, May 12, 2008 at 6:07 PM, Mark Harris <[EMAIL PROTECTED]> wrote:
Korny Sietsma wrote:
I'd be interested in the thoughts of folks here. A simple template
would have the advantage of (possibly) working well in css editors and
tools; but there also seems to be some buzz around tools like Sass
that take some more repetition out of the CSS.
Is SASS a standard? Nope. Will it work without HAML? Nope.
Then my thought would be that it's going to have issues somewhere (I'm not
familiar with it beyond a quick skim of the link you provided plus a glance
at Wikipedia so I can't say where exactly)
Or is there something else we should look at? Really, mostly we are
just looking for ways to avoid too much repetition - it'd be good to
avoid endlessly repeating colour codes and font sizes all over the
place, when we have a server-side language available that could build
our css for us.
Ummmm, I don't think you've fully grasped the nature of CSS, which is
designed specifically NOT to have you "endlessly repeating colour codes and
font sizes all over the place" by declaring the styles as classes and using
IDs to determine where to apply those classes.
Anything that's generated server-side is going to send unnecessary overhead
down to the browser. Letting the browser do the parsing and rendering (which
is what it has a rendering engine for) seems much more sensible.
Additionally, if you're not supplying properly formatted CSS, but something
preformatted at the server, how is the browser going to understand it? How
are assistive technologies going to understand it?
I may be missing something here but SASS has the feeling of a solution
looking for a problem, or a programmer wanting to get his credit for adding
something to RoR (which is the tech du jour). That's probably unfair, but
I've been doing accessibility testing all day and I'm kinda grouchy
mark
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
