Make the EZC CSS readable

[jfriend]

The CSS that is injected into our pages by the EZ Customizer is illegible. It's all crammed onto one line and doesn't even have a carriage return at the end which means it sucks up the first line of user CSS to make it invisible in the common tools Web Developer and Firebug.

If you ever want people who start with EZ Customizer to be able to grow into customizing their page with their own custom CSS and potentially even adding to the customization that EZC did, then the EZC stuff needs to be made readable in both Web Developer and Firebug.

If you ever want CSS helpers to not mind helping people using EZC without first suggesting that they get rid of EZC, then you also need to do this. In order to help, we need to be able to see what EZC is doing.

All that is required to accomplish this is to have some carriage returns in the EZC CSS and especially to have a carriage return at the end. It should be readable in Web Developer and Firebug. Today it is not. One carriage return per CSS rule please, just like you would do in your own CSS. Otherwise, it's too much of a pain to see what the EZC stuff is doing that I either skip helping those folks or I recommend they turn off EZC stuff before I can help them.

[denisegoldberg]

Funny, I was thinking the same thing.

And I too tend to stay away from questions when Easy Customizer has been used. I just recommended that someone remove the code when it seemed to totally block the look she was after. Adding !important to her code did absolutely nothing to override the EC code.

--- Denise

[Andy]

Allen pinged me on this last week, and I gave it to Brian. Brian's on his honeymoon right now! :clap :lust

Give us about a month. We'll get there.

[jfriend]

Allen pinged me on this last week, and I gave it to Brian. Brian's on his honeymoon right now! :clap :lust

Give us about a month. We'll get there. OK. One more request. Delineate the EZC CSS with comments so we can tell where it starts and stops and what is the user's CSS.

[Andy]

OK. One more request. Delineate the EZC CSS with comments so we can tell where it starts and stops and what is the user's CSS.
Makes perfect sense!

[Allen]

The injected header html also needs line breaks.:D

Question/discussion, if the injected html and CSS was copied with WebDev
and EZC is then reset removing it all. Then paste it into the user
header/CSS. From that point would customization proceed as normal? This
would mean that EZC could not be used again without first removing these
parts from the user code.

There are probably thousands using EZC with only a few wanting further
customization and for these this might be a starting point. We could just
supply them with their whole new html and CSS that includes the EZC parts
and tell them first to reset.
Any thoughts?

[jfriend]

The injected header html also needs line breaks.:D

Question/discussion, if the injected html and CSS was copied with WebDev
and EZC is then reset removing it all. Then paste it into the user
header/CSS. From that point would customization proceed as normal? This
would mean that EZC could not be used again without first removing these
parts from the user code.

There are probably thousands using EZC with only a few wanting further
customization and for these this might be a starting point. We could just
supply them with their whole new html and CSS that includes the EZC parts
and tell them first to reset.
Any thoughts? That could work, though it's like using a backhoe to pound in a nail. You get a lot more than you need.

My main issue with EZC is that even if the user only changes one setting in EZC, it injects a ton of new CSS that overrides things in themes and things in your existing user customization. It puts in new default values for lots of things and they are all marked !important. I would not want that junk in my site if I was trying to do manual customization because it makes it a lot harder than it needs to be. Now, if you you could sort through the myriad EZC CSS rules and keep only the ones you actually need, then this would work perfectly. But, that is not so easy.

The long term solution is to stop putting a zillion default rules into EZC with !important and have EZC only inject the settings that the user actually asked for (e.g. if they changed two settings in EZC, they get only the CSS rules for those settings). Default values for CSS rules belong in themes, not in EZC. Then, EZC would be fully compatible with themes and the stuff it injected would only be relevant to the features the user asked for. You could freely use EZC and manual customization along side one another, you could graduate from EZC to doing a little manual customization and helping people who had used EZC customize their site would be a lot easier.