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]
> *******************************************************************
>
>
--
Kornelis Sietsma korny at my surname dot com
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
