Re: [WSG] :: CSS Code Formatting ::
Hmm - we're currently debating what to do about dynamic css on our
project (Ruby on Rails based)
There seem to be a few options:
- No dynamic css at all
- Simple templated stuff, where the code is basically css + inline ruby:
#whatever { background-color : %= background_colour %; }
- Something that builds css from a difference css-like language like
Sass: http://haml.hamptoncatlin.com/docs/rdoc/classes/Sass.html
- Or something else...
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.
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.
- Korny
On Fri, May 9, 2008 at 3:13 PM, Adam Martin [EMAIL PROTECTED] wrote:
We use a very similar approach - php to deliver the css.
This allows us to do some very cool things, such as target browsers with
simple comments
For example:
/* IE
button {
width: auto;
overflow: visible;
}
button span {
margin-top: 2px;
}
*/
or we can even target browser versions
/* IE6
button {
width: auto;
overflow: visible;
}
button span {
margin-top: 2px;
}
*/
or even browsers and operating systems
/* Opera 9.10 Win
button {
width: auto;
overflow: visible;
}
button span {
margin-top: 2px;
}
*/
We also store basic css configuration into a config.ini file that can be
read by the php script, for example:
#-#
# LAYOUT DEFINITION
# style1 centered content, header and footer are fullscreen width
# style2 fullscreen
# style3 centered
# style4 header fullscreen, everything else centered
# style5 footer fullscreen, everything else centered
#-#
layout.style= style3;
layout.width= 758;
left.width = 185;
right.width = 0;
header.display = true;
footer.display = true;
body.bg = #FFF;
header.bg = #FFF;
left.bg = #dae2f0;
right.bg= #78746E;
main.bg = #FFF;
footer.bg = #FFF;
this sets up our basic layout for us, very quickly and easily. The true
power is in using some logic to produce the cs is that is needed. We can
then compress it all nicely, add a future expiry date, cache and we are good
to go.
Sorry, this seemed to get completely off topic, but I am sure it will spark
some conversations :)
Cheers
Adam
On Fri, 09 May 2008 14:46:34 +1000, David Hucklesby [EMAIL PROTECTED]
wrote:
On Tue, 6 May 2008 19:19:24 +0530, Amrinder wrote:
I was reading this article on Smashing Magazine which shows how to
increase code
readability,
http://www.smashingmagazine.com/2008/05/02/improving-code-readability-with-css-
styleguides/
but I have listened to Andy Clarke over Lynda.com saying that one should
save the white
space as it increases the file size.
Ted Drake replied:
Reduce the number of css files used
Link to them in the top of the page, no inline styles
Gzip and reduce the whitespace when going to production.
~~~
A job for a server-side script. See:
http://www.coolphptools.com/dynamic_css
Cordially,
David
--
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
***
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]
***
Re: [WSG] :: CSS Code Formatting ::
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. U, 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] ***
Re: [WSG] :: CSS Code Formatting ::
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 #33; }
#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 = #33;
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 #33 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 #33, 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 #33; }
#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.
U, 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]
***
RE: [WSG] :: CSS Code Formatting ::
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Adam Martin
Sent: Thursday, May 08, 2008 10:13 PM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] :: CSS Code Formatting ::
We use a very similar approach - php to deliver the css.
This allows us to do some very cool things, such as target browsers with
simple comments
For example:
/* IE
button {
width: auto;
overflow: visible;
}
button span {
margin-top: 2px;
}
*/
or we can even target browser versions
/* IE6
button {
width: auto;
overflow: visible;
}
button span {
margin-top: 2px;
}
*/
I'm not sure it is best practice to base the whole CSS logic on browser
sniffing.
Relying on browser *capabilities* sounds safer.
--
Regards,
Thierry | http://www.TJKDesign.com
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] :: CSS Code Formatting ::
On Tue, 6 May 2008 19:19:24 +0530, Amrinder wrote: I was reading this article on Smashing Magazine which shows how to increase code readability, http://www.smashingmagazine.com/2008/05/02/improving-code-readability-with-css- styleguides/ but I have listened to Andy Clarke over Lynda.com saying that one should save the white space as it increases the file size. Ted Drake replied: Reduce the number of css files used Link to them in the top of the page, no inline styles Gzip and reduce the whitespace when going to production. ~~~ A job for a server-side script. See: http://www.coolphptools.com/dynamic_css Cordially, David -- *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] :: CSS Code Formatting ::
On Tue, May 6, 2008 at 2:49 PM, Amrinder [EMAIL PROTECTED] wrote: Which approach is better? Should we go for code readability as described by Smashing Magazine or follow what Andy said. Why not do both? Use a coding style that suits you, then compress it for live deployment. -- - Matthew *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] :: CSS Code Formatting ::
Amrinder wrote: I was reading this article on Smashing Magazine which shows how to increase code readability but I have listened to Andy Clarke ... saying that one should save the white space as it increases the file size. Which approach is better? Should we go for code readability as described by Smashing Magazine or follow what Andy said. Do you have enough page views that your bandwidth cost is killing you? Will removing a couple of dozen tab characters in your style sheet result in a better user experience? If so, pull the white space. Personally, I'd worry more about the ease of maintenance, especially if more than one person's working on the site. :-) Or have the best of both: formatted for readability in your version control repository, with a script to run at deploy time to check the markup+css out and minimize it. FWIW, -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-621-3445 === http://webtuitive.com dream. code. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] :: CSS Code Formatting ::
Ultimately you want to use one version during your development process (to ensure readability between your development team) but then have a smaller/compacted version to be used once you deploy to the live server (and at which point it's not the end of the world if your CSS is difficult to read) A best of both worlds approach ;- - Original Message From: Amrinder [EMAIL PROTECTED] To: WebStandards Discussion Lish wsg@webstandardsgroup.org Sent: Tuesday, 6 May, 2008 2:49:24 PM Subject: [WSG] :: CSS Code Formatting :: Which approach is better? Should we go for code readability as described by Smashing Magazine or follow what Andy said. __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] :: CSS Code Formatting ::
From Yslow http://developer.yahoo.com/performance/ Reduce the number of css files used Link to them in the top of the page, no inline styles Gzip and reduce the whitespace when going to production. These are fairly simple steps for the average web developer. Visit yslow for more performance tips. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Bruniges Sent: Tuesday, May 06, 2008 4:31 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] :: CSS Code Formatting :: Ultimately you want to use one version during your development process (to ensure readability between your development team) but then have a smaller/compacted version to be used once you deploy to the live server (and at which point it's not the end of the world if your CSS is difficult to read) A best of both worlds approach ;- - Original Message From: Amrinder [EMAIL PROTECTED] To: WebStandards Discussion Lish wsg@webstandardsgroup.org Sent: Tuesday, 6 May, 2008 2:49:24 PM Subject: [WSG] :: CSS Code Formatting :: Which approach is better? Should we go for code readability as described by Smashing Magazine or follow what Andy said. _ Sent from Yahoo! Mail http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http:/us.rd.yahoo.com/e vt=52418/*http:/uk.docs.yahoo.com/nowyoucan.html . A Smarter Email. *** 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] ***
