Re: [WSG] An efficient CSS architecture
For our "custom" projects at my work we have recently adopted the Tripoli<http://devkick.com/lab/tripoli/>and combine.php <http://rakaz.nl/projects/combine/combine.phps> for compression (+gzip done by the server). On top of Tripoli; I have created our on in-house CSS framework/template that gets me 85-90% of the CSS I need for each site based on HTML standards we code with. Best Regards, Nate Hanna On Mon, Apr 28, 2008 at 6:07 AM, <[EMAIL PROTECTED]> wrote: > For me, assuming you are 100% sure about your compression scheme, is to do > all of your debugging against a test site (with no compression). > This is what I do with my main site; the take-live process copies files > from my test site, via a staging site, on to the live server. The process > also handles copyright dates, build numbers, comment removal and some light > compression/optimisation. Because I wrote this script from the ground up I > was able to keep the compression reasonable too: a few line breaks aren't > the end of the world in terms of size, but allow me to do enough debugging > on the live system to tell roughly where things are going wrong on the odd > occasion where something gets by. (9 times out of 10that is because I have > missed a dependant file!) > > Mike > > -Original Message- > From: [EMAIL PROTECTED] on behalf of Jens-Uwe Korff > Sent: Mon 28/04/2008 08:27 > To: wsg@webstandardsgroup.org > Subject: RE: [WSG] An efficient CSS architecture > > > > I am currently looking into CSS compression. This has, however, the > disadvantage of removing effective live debugging with Firebug because > all CSS rules will be on one single line. How do you address this > problem? > > > *** > 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] An efficient CSS architecture
For me, assuming you are 100% sure about your compression scheme, is to do all of your debugging against a test site (with no compression). This is what I do with my main site; the take-live process copies files from my test site, via a staging site, on to the live server. The process also handles copyright dates, build numbers, comment removal and some light compression/optimisation. Because I wrote this script from the ground up I was able to keep the compression reasonable too: a few line breaks aren't the end of the world in terms of size, but allow me to do enough debugging on the live system to tell roughly where things are going wrong on the odd occasion where something gets by. (9 times out of 10that is because I have missed a dependant file!) Mike -Original Message- From: [EMAIL PROTECTED] on behalf of Jens-Uwe Korff Sent: Mon 28/04/2008 08:27 To: wsg@webstandardsgroup.org Subject: RE: [WSG] An efficient CSS architecture I am currently looking into CSS compression. This has, however, the disadvantage of removing effective live debugging with Firebug because all CSS rules will be on one single line. How do you address this problem? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** <>
RE: [WSG] An efficient CSS architecture
Hi Paul, thanks for your thoughts. Could you share why you went for Yahoo YUI rather than e.g. Blueprint CSS? Please explain to me what you mean with CSS for a "creative workgroup" and "dev workgroup". Why is this distinction necessary? I am currently looking into CSS compression. This has, however, the disadvantage of removing effective live debugging with Firebug because all CSS rules will be on one single line. How do you address this problem? I'm actually questioning the approach to use IDs because they have such a strong specificity. I'm aiming for using them only if Javascript dictates it or if we really, really need them. Otherwise I'd rather use a class. Cheers, Jens -Original Message- This was before we adopted the Yahoo YUI for our in-house development. I'd suggest you create separate CSS files and workflows for a creative workgroup and a development workgroup (content.css and controls.css) as both departments will want to release unique controls and content elements that won't be able to pick up the existing styles. This will relieve pressure on the framework CSS files. I'd suggest that CSS be added to a project and validated before going out, and use ID to isolate areas where you can. You should be able to clean out the content.css and controls.css files periodically. The multiple stylesheets are a concern, but your base framework can be combined and compressed and served from somewhere else as others have suggested. You can do much the same for the javascript too. Cheers Paul The information contained in this e-mail message and any accompanying files is or may be confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail is subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. Fairfax does not guarantee the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore Fairfax does not accept legal responsibility for the contents of this message or attached files. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] An efficient CSS architecture
Jens, I worked up something for www.iasbet.com which was reasonably robust. This was before we adopted the Yahoo YUI for our in-house development. I'd suggest you create separate CSS files and workflows for a creative workgroup and a development workgroup (content.css and controls.css) as both departments will want to release unique controls and content elements that won't be able to pick up the existing styles. This will relieve pressure on the framework CSS files. I'd suggest that CSS be added to a project and validated before going out, and use ID to isolate areas where you can. You should be able to clean out the content.css and controls.css files periodically. The multiple stylesheets are a concern, but your base framework can be combined and compressed and served from somewhere else as others have suggested. You can do much the same for the javascript too. Cheers Paul Paul Minty Director mintleaf studio We design & create stylish websites Post: Box 6 108 Flinders Street Melbourne VIC 3000 Level 2 108 Flinders Street Melbourne T. 03 9662 9344 F. 03 9662 9255 M. 0418 307 475 [EMAIL PROTECTED] www.mintleafstudio.com.au > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jens-Uwe Korff > Sent: Thursday, 24 April 2008 4:31 PM > To: wsg@webstandardsgroup.org > Subject: [WSG] An efficient CSS architecture > Importance: Low > > Hi all, > > I'm currently in the lucky position to be able to design a > CSS architecture from scratch. I was thinking of creating a > layered approach where I have a CSS layer for > > - the CSS reset > - the site layout (structural parts, ie. columns, rows, > header, footer) > - the site's elements (boxes which can be reused across > pages; a box might contain images, heading, paragraphs) > - the site's skin (colours, sprites etc.) > > I'd like to know if you have been through this thought > process and if you have proven concepts that you would like to share. > > (You can email me offline too, but we've got a long weekend > here so I'll contact you Monday.) > > Thank you! > > Cheers, > > Jens > > The information contained in this e-mail message and any > accompanying files is or may be confidential. If you are not > the intended recipient, any use, dissemination, reliance, > forwarding, printing or copying of this e-mail or any > attached files is unauthorised. This e-mail is subject to > copyright. No part of it should be reproduced, adapted or > communicated without the written consent of the copyright > owner. If you have received this e-mail in error please > advise the sender immediately by return e-mail or telephone > and delete all copies. Fairfax does not guarantee the > accuracy or completeness of any information contained in this > e-mail or attached files. Internet communications are not > secure, therefore Fairfax does not accept legal > responsibility for the contents of this message or attached files. > > > *** > 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] An efficient CSS architecture
The Yahoo YUI CSS framework is a big help. http://developer.yahoo.com/yui/ The Reset, base, and fonts give you a good foundation. The grids make it super easy to build layouts. Combine all four into a single css file: http://yui.yahooapis.com/2.5.1/build/reset-fonts-grids/reset-fonts-grids.css And you've got some good performance. The above link means Yahoo handles the distributed caching for you. This means you only have to concentrate on what makes your sites unique. You'll be surprised how lean and efficient your final css markup is when you remove the foundation cruft. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karl Lurman Sent: Thursday, April 24, 2008 8:42 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] An efficient CSS architecture Jens, I recommend googling CSS Frameworks. Also, I recommend looking at a site I implemented a CSS framework of my own. It sounds very very much like your approach. http://www.athletics.com.au It works on the concept of layers that can be used to progressively enhance the visual appearance of a given HTML document set. Its actually the base css framework for a content management solution developed by a company called Datalink here in Melbourne, my previous job. Being part of a CMS, it has a few additional layers to further customise the site with respect to customer requirement. Similarly, I used namespacing to separate styles that are part of the base framework with styles that are customer specific. The beauty of the framework is that it is consistent and easy to learn. The idea being that the framework remained unchanged, and only theme and customer specifc stylesheets affected the cascade. Another added benefit was in knowing which sheet a specific style resides in. This was extremely helpful before the likes of Firebug. The only real draw back of this approach is the initial page load. There is an overhead in downloading so many different stylesheets. The best thing to do in this case is to compile your stylesheets into a single build. This is the approach we are applying at my current job here at SitePoint. Good luck with your own framework! :) Karl On Thu, Apr 24, 2008 at 4:05 PM, Jens-Uwe Korff <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm currently in the lucky position to be able to design a CSS > architecture from scratch. I was thinking of creating a layered approach > where I have a CSS layer for > > - the CSS reset > - the site layout (structural parts, ie. columns, rows, header, footer) > - the site's elements (boxes which can be reused across pages; a box > might contain images, heading, paragraphs) > - the site's skin (colours, sprites etc.) > > I'd like to know if you have been through this thought process and if > you have proven concepts that you would like to share. > > (You can email me offline too, but we've got a long weekend here so I'll > contact you Monday.) > > Thank you! > > Cheers, > > Jens > > The information contained in this e-mail message and any accompanying files is or may be confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail is subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. Fairfax does not guarantee the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore Fairfax does not accept legal responsibility for the contents of this message or attached files. > > > *** > 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] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] An efficient CSS architecture
Jens, I recommend googling CSS Frameworks. Also, I recommend looking at a site I implemented a CSS framework of my own. It sounds very very much like your approach. http://www.athletics.com.au It works on the concept of layers that can be used to progressively enhance the visual appearance of a given HTML document set. Its actually the base css framework for a content management solution developed by a company called Datalink here in Melbourne, my previous job. Being part of a CMS, it has a few additional layers to further customise the site with respect to customer requirement. Similarly, I used namespacing to separate styles that are part of the base framework with styles that are customer specific. The beauty of the framework is that it is consistent and easy to learn. The idea being that the framework remained unchanged, and only theme and customer specifc stylesheets affected the cascade. Another added benefit was in knowing which sheet a specific style resides in. This was extremely helpful before the likes of Firebug. The only real draw back of this approach is the initial page load. There is an overhead in downloading so many different stylesheets. The best thing to do in this case is to compile your stylesheets into a single build. This is the approach we are applying at my current job here at SitePoint. Good luck with your own framework! :) Karl On Thu, Apr 24, 2008 at 4:05 PM, Jens-Uwe Korff <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm currently in the lucky position to be able to design a CSS > architecture from scratch. I was thinking of creating a layered approach > where I have a CSS layer for > > - the CSS reset > - the site layout (structural parts, ie. columns, rows, header, footer) > - the site's elements (boxes which can be reused across pages; a box > might contain images, heading, paragraphs) > - the site's skin (colours, sprites etc.) > > I'd like to know if you have been through this thought process and if > you have proven concepts that you would like to share. > > (You can email me offline too, but we've got a long weekend here so I'll > contact you Monday.) > > Thank you! > > Cheers, > > Jens > > The information contained in this e-mail message and any accompanying files > is or may be confidential. If you are not the intended recipient, any use, > dissemination, reliance, forwarding, printing or copying of this e-mail or > any attached files is unauthorised. This e-mail is subject to copyright. No > part of it should be reproduced, adapted or communicated without the written > consent of the copyright owner. If you have received this e-mail in error > please advise the sender immediately by return e-mail or telephone and delete > all copies. Fairfax does not guarantee the accuracy or completeness of any > information contained in this e-mail or attached files. Internet > communications are not secure, therefore Fairfax does not accept legal > responsibility for the contents of this message or attached files. > > > *** > 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] ***