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
 
<snip>

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

<<winmail.dat>>

Reply via email to