Comments on: Modularised stuff – where to draw the line? http://www.markboulton.co.uk/journal/comments/modularised-stuff-where-to-draw-the-line?utm_source=rss&utm_medium=rss&utm_campaign=modularised-stuff-where-to-draw-the-line The Personal Disquiet of Mark Boulton Thu, 09 Feb 2012 18:39:01 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Terrence Wood http://www.markboulton.co.uk/journal/comments/modularised-stuff-where-to-draw-the-line#comment-612 Terrence Wood Sun, 26 Jun 2005 08:06:47 +0000 http://wordpress.markboultondesignhosting.com/2005/06/modularised-stuff-where-to-draw-the-line/#comment-612 <p>I’ve experimented with multiple methods over the years for organising CSS, and the conclusion that I’ve come to is that I like to send the smallest amount of data with the least number of trips to the server… </p> <p> So, I organise my CSS by roughly following the HTML source, or functional grouping (header, content, nav,footer). I try and fit it all into one file, and use the cascade as much as possible—minimizing classitis and iditis. Occasionally, I use page specific CSS in the documenthead, but if it’s needed in more than a couple of pages it goes in the CSS file. </p> <p> I develop in the most standards compliant browser available, and put any hacks, if needed, at the end of the file as I build up support for not-so-compliant browsers. </p> <p> Usually I only need the <code>* html</code> hack, and a comment hack for IE5/Mac. If I have more than a couple of IE specific rules, or I’m using expressions then I’ll use conditional comments. </p> <p> I comment my working files and compress anything sent to a browser. </p> <p> For me it comes down to how best deliver data quickly, and so I’ll adjust my method’s depending on the requirements of the project. </p> I’ve experimented with multiple methods over the years for organising CSS, and the conclusion that I’ve come to is that I like to send the smallest amount of data with the least number of trips to the server…

So, I organise my CSS by roughly following the HTML source, or functional grouping (header, content, nav,footer). I try and fit it all into one file, and use the cascade as much as possible—minimizing classitis and iditis. Occasionally, I use page specific CSS in the documenthead, but if it’s needed in more than a couple of pages it goes in the CSS file.

I develop in the most standards compliant browser available, and put any hacks, if needed, at the end of the file as I build up support for not-so-compliant browsers.

Usually I only need the * html hack, and a comment hack for IE5/Mac. If I have more than a couple of IE specific rules, or I’m using expressions then I’ll use conditional comments.

I comment my working files and compress anything sent to a browser.

For me it comes down to how best deliver data quickly, and so I’ll adjust my method’s depending on the requirements of the project.

]]> By: Pio Rasch-Halvorsen http://www.markboulton.co.uk/journal/comments/modularised-stuff-where-to-draw-the-line#comment-614 Pio Rasch-Halvorsen Fri, 24 Jun 2005 06:55:09 +0000 http://wordpress.markboultondesignhosting.com/2005/06/modularised-stuff-where-to-draw-the-line/#comment-614 <p><strong>Gerard McGarry:</strong> When specifying media types in CSS, you should let the “screen” stylesheet apply to the “projection” media as well or the page will be unstyled in Opera’s fullscreen mode. Unless you have a separate “projection” style, that is. </p> <p> To get back on topic; I tend to use flagged CSS for my projects. However I’m usually working on small-scale, personal projects with relatively few styled entities. </p> Gerard McGarry: When specifying media types in CSS, you should let the “screen” stylesheet apply to the “projection” media as well or the page will be unstyled in Opera’s fullscreen mode. Unless you have a separate “projection” style, that is.

To get back on topic; I tend to use flagged CSS for my projects. However I’m usually working on small-scale, personal projects with relatively few styled entities.

]]> By: Gerard McGarry http://www.markboulton.co.uk/journal/comments/modularised-stuff-where-to-draw-the-line#comment-613 Gerard McGarry Tue, 21 Jun 2005 04:57:47 +0000 http://wordpress.markboultondesignhosting.com/2005/06/modularised-stuff-where-to-draw-the-line/#comment-613 <p>I tend to work my stylesheets toward the two main media types (screen and print) - I’m not sure how advisable that is, but it helps me keep track of things fairly well. </p> <p> I tend to develop the screen stylesheet first, until I have everything looking as needed. Then I revise the design for a print style, removing the navigation and any superflous features that are likely to waste paper of affect legibility. </p> <p> I’d be more inclined to use flags/comments within the CSS for easier navigation. </p> I tend to work my stylesheets toward the two main media types (screen and print) – I’m not sure how advisable that is, but it helps me keep track of things fairly well.

I tend to develop the screen stylesheet first, until I have everything looking as needed. Then I revise the design for a print style, removing the navigation and any superflous features that are likely to waste paper of affect legibility.

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

]]> By: Mark Boulton http://www.markboulton.co.uk/journal/comments/modularised-stuff-where-to-draw-the-line#comment-615 Mark Boulton Fri, 03 Jun 2005 03:35:11 +0000 http://wordpress.markboultondesignhosting.com/2005/06/modularised-stuff-where-to-draw-the-line/#comment-615 <p><strong>Urban</strong> - I’ll refer you to the ‘Allowed tags’ note at the side of the comment field. Lists aren’t allowed and the html gets stripped. </p> <p> <strong>Allan</strong> - There are several backend’s, from EE to totally bespoke. </p> <p> Your method of CSS files is pretty much how I’ve done it in the past, including on this site, I have a ‘screen.css’ which imports all the others. The problem then comes with maintenance and visibility if the team editing it is more than one person. </p> <p> What I’m getting at is at what point does modularisation increase, rather than decrease, ongoing support? As in, somebody has to search through several files, then change them, then remember which one’s they were (and in what place) to upload them… </p> Urban – I’ll refer you to the ‘Allowed tags’ note at the side of the comment field. Lists aren’t allowed and the html gets stripped.

Allan – There are several backend’s, from EE to totally bespoke.

Your method of CSS files is pretty much how I’ve done it in the past, including on this site, I have a ‘screen.css’ which imports all the others. The problem then comes with maintenance and visibility if the team editing it is more than one person.

What I’m getting at is at what point does modularisation increase, rather than decrease, ongoing support? As in, somebody has to search through several files, then change them, then remember which one’s they were (and in what place) to upload them…

]]> By: Allan White http://www.markboulton.co.uk/journal/comments/modularised-stuff-where-to-draw-the-line#comment-617 Allan White Fri, 03 Jun 2005 03:26:34 +0000 http://wordpress.markboultondesignhosting.com/2005/06/modularised-stuff-where-to-draw-the-line/#comment-617 <p>What kind of backend are you thinking? Are you looking at Expression Engine for client projects? I wrestle with this all the time with EE templating (using {embed}). EE doesn’t (at present) make it really easy to pass variables to nested templates, so it’s mostly hacking at this point. </p> <p> I’m with you on the “level of granularity” thing. I try to get the big chunks (low-hanging fruit) in separate CSS files, and then put page-specific stuff on individual pages. I like having one ‘global.css’ that @imports the others (fonts.css, positioning.css, etc.). It really depends, for me, how similar the templates are as you go into the site. </p> What kind of backend are you thinking? Are you looking at Expression Engine for client projects? I wrestle with this all the time with EE templating (using {embed}). EE doesn’t (at present) make it really easy to pass variables to nested templates, so it’s mostly hacking at this point.

I’m with you on the “level of granularity” thing. I try to get the big chunks (low-hanging fruit) in separate CSS files, and then put page-specific stuff on individual pages. I like having one ‘global.css’ that @imports the others (fonts.css, positioning.css, etc.). It really depends, for me, how similar the templates are as you go into the site.

]]> By: Urban Faubion http://www.markboulton.co.uk/journal/comments/modularised-stuff-where-to-draw-the-line#comment-616 Urban Faubion Fri, 03 Jun 2005 03:11:21 +0000 http://wordpress.markboultondesignhosting.com/2005/06/modularised-stuff-where-to-draw-the-line/#comment-616 <p>Note: “Live Preview” doesn’t match the end result when you publishing comments. # was intended to be an ordered list. </p> Note: “Live Preview” doesn’t match the end result when you publishing comments. # was intended to be an ordered list.

]]> By: Urban Faubion http://www.markboulton.co.uk/journal/comments/modularised-stuff-where-to-draw-the-line#comment-618 Urban Faubion Fri, 03 Jun 2005 03:07:08 +0000 http://wordpress.markboultondesignhosting.com/2005/06/modularised-stuff-where-to-draw-the-line/#comment-618 <p>I tend to break down a sites into a series of includes that my content pages call.  These are global elements in my design (header, navigation, footer, etc) that will stay consistent for branding purposes.  My CSS files tend to mirror this structure and I add additional CSS files for page specific content when needed.<blockquote><p> # base.css <br /> # global.css <br /> # structure.css <br /> # <em>page specific css</em> <br /> # header.css <br /> # navigation.css <br /> # footer.css <br /> </p></blockquote> I tend to break down a sites into a series of includes that my content pages call.  These are global elements in my design (header, navigation, footer, etc) that will stay consistent for branding purposes.  My CSS files tend to mirror this structure and I add additional CSS files for page specific content when needed.

# base.css

# global.css

# structure.css

# page specific css

# header.css

# navigation.css

# footer.css

]]> By: JohnO http://www.markboulton.co.uk/journal/comments/modularised-stuff-where-to-draw-the-line#comment-619 JohnO Fri, 03 Jun 2005 02:10:42 +0000 http://wordpress.markboultondesignhosting.com/2005/06/modularised-stuff-where-to-draw-the-line/#comment-619 <p>’practical’ btw.. </p> <p> I’ve modularised in my web-applications thusly: </p> <p> 1. Index CSS file (global properties common for all elements) </p> <p> 2. page level CSS files (where layout might differ, or content mandates changing padding/margins) </p> <p> 3. inline styles on certain pages where I want an exception (overriding a global property) (no reason they are inline really.. they could very well be in the page level CSS) </p> <p> I have one exception, in that I had one module of code for Validating form fields, and I’ve seperated the CSS for that.(required label colors, and various and sundry things).... </p> ’practical’ btw..

I’ve modularised in my web-applications thusly:

1. Index CSS file (global properties common for all elements)

2. page level CSS files (where layout might differ, or content mandates changing padding/margins)

3. inline styles on certain pages where I want an exception (overriding a global property) (no reason they are inline really.. they could very well be in the page level CSS)

I have one exception, in that I had one module of code for Validating form fields, and I’ve seperated the CSS for that.(required label colors, and various and sundry things)….

]]>