Mark Boulton

8 Responses to “Modularised stuff — where to draw the line?”

1. 
   JohnO said on: June 2nd, 2005 at 6:10 pm

   ’prac­tical’ btw.. 

   I’ve mod­u­lar­ised in my web-applications thusly: 

   1. Index CSS file (global prop­er­ties com­mon for all elements) 

   2. page level CSS files (where lay­out might dif­fer, or con­tent man­dates chan­ging padding/margins)

   3. inline styles on cer­tain pages where I want an excep­tion (over­rid­ing a global prop­erty) (no reason they are inline really.. they could very well be in the page level CSS) 

   I have one excep­tion, in that I had one mod­ule of code for Val­id­at­ing form fields, and I’ve seper­ated the CSS for that.(required label col­ors, and vari­ous and sun­dry things).…

2. 
   Urban Faubion said on: June 2nd, 2005 at 7:07 pm

   I tend to break down a sites into a series of includes that my con­tent pages call.  These are global ele­ments in my design (header, nav­ig­a­tion, footer, etc) that will stay con­sist­ent for brand­ing pur­poses.  My CSS files tend to mir­ror this struc­ture and I add addi­tional CSS files for page spe­cific con­tent when needed.
   

   # base.css
   

   # global.css
   
   # structure.css
   
   # page spe­cific css
   
   # header.css
   
   # navigation.css
   
   # footer.css
   

3. 
   Urban Faubion said on: June 2nd, 2005 at 7:11 pm

   Note: “Live Pre­view” doesn’t match the end res­ult when you pub­lish­ing com­ments. # was inten­ded to be an ordered list.

4. 
   Allan White said on: June 2nd, 2005 at 7:26 pm

   What kind of backend are you think­ing? Are you look­ing at Expres­sion Engine for cli­ent pro­jects? I wrestle with this all the time with EE tem­plat­ing (using {embed}). EE doesn’t (at present) make it really easy to pass vari­ables to nes­ted tem­plates, so it’s mostly hack­ing at this point. 

   I’m with you on the “level of gran­u­lar­ity” thing. I try to get the big chunks (low-hanging fruit) in sep­ar­ate CSS files, and then put page-specific stuff on indi­vidual pages. I like hav­ing one ‘global.css’ that @imports the oth­ers (fonts.css, positioning.css, etc.). It really depends, for me, how sim­ilar the tem­plates are as you go into the site.

5. 
   Mark Boulton said on: June 2nd, 2005 at 7:35 pm

   Urban — I’ll refer you to the ‘Allowed tags’ note at the side of the com­ment field. Lists aren’t allowed and the html gets stripped. 

   Allan — There are sev­eral backend’s, from EE to totally bespoke. 

   Your method of CSS files is pretty much how I’ve done it in the past, includ­ing on this site, I have a ‘screen.css’ which imports all the oth­ers. The prob­lem then comes with main­ten­ance and vis­ib­il­ity if the team edit­ing it is more than one person. 

   What I’m get­ting at is at what point does mod­u­lar­isa­tion increase, rather than decrease, ongo­ing sup­port? As in, some­body has to search through sev­eral files, then change them, then remem­ber which one’s they were (and in what place) to upload them…

6. 
   Gerard McGarry said on: June 20th, 2005 at 8:57 pm

   I tend to work my stylesheets toward the two main media types (screen and print) — I’m not sure how advis­able that is, but it helps me keep track of things fairly well. 

   I tend to develop the screen stylesheet first, until I have everything look­ing as needed. Then I revise the design for a print style, remov­ing the nav­ig­a­tion and any super­flous fea­tures that are likely to waste paper of affect legibility. 

   I’d be more inclined to use flags/comments within the CSS for easier navigation.

7. 
   Pio Rasch-Halvorsen said on: June 23rd, 2005 at 10:55 pm

   Ger­ard McGarry: When spe­cify­ing media types in CSS, you should let the “screen” stylesheet apply to the “pro­jec­tion” media as well or the page will be unstyled in Opera’s full­screen mode. Unless you have a sep­ar­ate “pro­jec­tion” style, that is.

   To get back on topic; I tend to use flagged CSS for my pro­jects. How­ever I’m usu­ally work­ing on small-scale, per­sonal pro­jects with rel­at­ively few styled entities.

8. 
   Terrence Wood said on: June 26th, 2005 at 12:06 am

   I’ve exper­i­mented with mul­tiple meth­ods over the years for organ­ising CSS, and the con­clu­sion that I’ve come to is that I like to send the smal­lest amount of data with the least num­ber of trips to the server… 

   So, I organ­ise my CSS by roughly fol­low­ing the HTML source, or func­tional group­ing (header, con­tent, nav,footer). I try and fit it all into one file, and use the cas­cade as much as possible—minimizing clas­sitis and iditis. Occa­sion­ally, I use page spe­cific CSS in the doc­u­ment­head, but if it’s needed in more than a couple of pages it goes in the CSS file. 

   I develop in the most stand­ards com­pli­ant browser avail­able, and put any hacks, if needed, at the end of the file as I build up sup­port for not-so-compliant browsers. 

   Usu­ally I only need the * html hack, and a com­ment hack for IE5/Mac. If I have more than a couple of IE spe­cific rules, or I’m using expres­sions then I’ll use con­di­tional comments. 

   I com­ment my work­ing files and com­press any­thing sent to a browser. 

   For me it comes down to how best deliver data quickly, and so I’ll adjust my method’s depend­ing on the require­ments of the project.