Re: [WSG] Global and page-specific style sheets

2007-03-14 Thread Jean-Jacques Halans

Have a look at the Adobe.com website, see what they are doing (talking
about massive).

I also tend to divide layout/fonts/colours into separate files.
You could then have different colour templates, font templates (where
font sizes change for example), etc.

As css files can become big, I think we need two versions, a
development version and a production version, same as what you see
with js files. You don't write css files to have pretty/commented
code, you write them for a browser to interpret. You have tools like
TopStyle which can automatically collapse and expand style
definitions, for example.
This site has an overview on CSS optimization tools (haven't used any
myself though, only topstyle):
http://www.bloggingpro.com/archives/2006/08/17/css-optimization/
or online tools: http://www.cssdev.com/csstweak/  or
http://www.cssoptimiser.com/
Although when compressing css, I guess you have to watch out for any
browser hacks (which you should avoid anyway).

Also, have separate development files, and then combine them into one
for production (not if you want to do templating with css of course).
Standard browser settings only allow for 2 simultaneous HTTP requests
from a single domain, so many request for small files will slow down
the (initial) page load. But it has pros and contras, especially if
you update often for example. Have a read on this Vitamin article:
http://www.thinkvitamin.com/features/webapps/serving-javascript-fast.

Hope it helps,
regards,
JJ


On 3/13/07, Cole Kuryakin [EMAIL PROTECTED] wrote:

Hello All –


I've got a site that has a fairly MASSIVE style sheet. It's quite long as
the design spec dictates a number of different pages be layed-out
differently.

Are there any best practice guidelines for such an issue?



Cole

***
List Guidelines:
http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe:
http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



--
Halans Jean-Jacques



http://www.halans.be
http://del.icio.us/halans
http://www.flickr.com/photos/halans/
http://halans.vox.com/




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Global and page-specific style sheets

2007-03-13 Thread Kevin Futter
On 13/3/07 3:01 PM, Cole Kuryakin [EMAIL PROTECTED] wrote:

 Hello All ­
  
 I¹ve got a site that has a fairly MASSIVE style sheet. It¹s quite long as the
 design spec dictates a number of different pages be layed-out differently.
  
 Accordingly, its becoming quite tedious to find certain style blocks that need
 to be altered/tweaked as development continues.
  
 So, I¹m beginning to think that the better way to accomplish this is to attach
 a ³global² sheet in the head that would take care of all ³generic² issues and
 page requirements.
  
 Then, in those pages that need ³special handling² I would attached separate
 sheets that would address page-specific requirements.
  
 BTW: This site is a dynamic one (php) so these special-case pages are
 ³included² depending on query-string variables/conditions.
  
 What do the good folks say here about this particular topic? Is this a normal
 (and preferred) workflow when one has to deal with long and unwieldy style
 sheets?
  
 Are there any ³best practice² guidelines for such an issue?
  
 Cole
  
I usually do that as a matter of course ­ one global style sheet that I
usually call Œdefault.css¹, which sets up all the default styles (no
kidding?), and then a page- or section-specific style sheet to deal with
the, well, specifics (man, I think I see a pattern here...). I find that it
makes managing larger sites much easier.

-- 
Kevin Futter
Webmaster, St. Bernard's College
http://www.sbc.melb.catholic.edu.au/


#
This e-mail message has been scanned for Viruses and Content and cleared 
by MailMarshal
#

This e-mail and any attachments may be confidential. You must not disclose or 
use the information in this e-mail if you are not the intended recipient. If 
you have received this e-mail in error, please notify us immediately and delete 
the e-mail and all copies. The College does not guarantee that this e-mail is 
virus or error free.  The attached files are provided and may only be used on 
the basis that the user assumes all responsibility for any loss, damage or 
consequence resulting directly or indirectly from the use of the attached 
files, whether caused by the negligence of the sender or not. The content and 
opinions in this e-mail are not necessarily those of the College.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***


RE: [WSG] Global and page-specific style sheets

2007-03-13 Thread Paul Bennett
One of the best things we did was to follow Doug Bowmans (webstock '06) 
suggestion to break up stylesheets into logical components and include them in 
one main file.

Our 'styles.css' file now looks like this:
-
@import url(styles-contentTables.css);
@import url(styles-forms.css);
@import url(styles-mainnav.css);
@import url(styles-popups.css);
@import url(styles-secondarynav.css);
@import url(styles-textformatting.css);

/* generic rules go here */
---

It may take a while, but I promise you you'll thank yourself later on :)
It was great advice and we've never regretted it.
Paul


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Global and page-specific style sheets

2007-03-13 Thread Chris Williams
OK, I'll bite... Why is this better than one, nicely formatted and commented
file?  It would seem to me that your way would be significantly slower to
load, and harder to find things in (where is that #main_title div
again...).  

It would seem that there must be major advantages to this I'm not seeing.
Care to enlighten?

 From: Paul Bennett [EMAIL PROTECTED]
 Subject: RE: [WSG] Global and page-specific style sheets
 
 One of the best things we did was to follow Doug Bowmans (webstock '06)
 suggestion to break up stylesheets into logical components and include them in
 one main file.
 
 Our 'styles.css' file now looks like this:
 -
 @import url(styles-contentTables.css);
 @import url(styles-forms.css);
 @import url(styles-mainnav.css);
 @import url(styles-popups.css);
 @import url(styles-secondarynav.css);
 @import url(styles-textformatting.css);
 
 /* generic rules go here */
 ---



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



RE: [WSG] Global and page-specific style sheets

2007-03-13 Thread Paul Bennett
Hi Chris,

Basically if I'm looking to change something in the main nav, I look in 
mainnav.css, if I'm altering a header for a table in our content area, I look 
in   contentTables.css etc, etc.

The main file was 30K (!) before we started trimming it down and breaking up. 
Yes it's more http connections, but it is *way* easier to find things and  
easier to maintain.

I understand where you're coming from for small css files, but for large sites 
and applications splitting up the files is (in my opinion) invaluable.

Paul


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Global and page-specific style sheets

2007-03-13 Thread John Faulds
Basically if I'm looking to change something in the main nav, I look in  
mainnav.css, if I'm altering a header for a table in our content area, I  
look in   contentTables.css etc, etc.


Or if you've got Firebug, right-click on an element, 'Inspect element' and  
it tells you exactly what line of your CSS file it's on. ;)


--
Tyssen Design
www.tyssendesign.com.au
Ph: (07) 3300 3303
Mb: 0405 678 590


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



RE: [WSG] Global and page-specific style sheets

2007-03-12 Thread Samuel Richardson
I don't have a problem with it, in fact the site I'm working on at the
moment has 30 separate style sheets. However, remember that every style
sheet will be a separate HTTP connection to retrieve it, so no matter how
fast someone's connection is, they still have to make multiple HTTP requests
to download all the documents, thus slowing down the site. Once the style
sheets are cached then this delay will be reduced.

 

 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Cole Kuryakin
Sent: Tuesday, 13 March 2007 3:01 PM
To: wsg@webstandardsgroup.org
Subject: [WSG] Global and page-specific style sheets

 

Hello All -

 

I've got a site that has a fairly MASSIVE style sheet. It's quite long as
the design spec dictates a number of different pages be layed-out
differently.

 

Accordingly, its becoming quite tedious to find certain style blocks that
need to be altered/tweaked as development continues.

 

So, I'm beginning to think that the better way to accomplish this is to
attach a global sheet in the head that would take care of all generic
issues and page requirements.

 

Then, in those pages that need special handling I would attached separate
sheets that would address page-specific requirements.

 

BTW: This site is a dynamic one (php) so these special-case pages are
included depending on query-string variables/conditions.

 

What do the good folks say here about this particular topic? Is this a
normal (and preferred) workflow when one has to deal with long and unwieldy
style sheets?

 

Are there any best practice guidelines for such an issue?

 

Cole

 

 

 


***
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]
***