[development] websiteoptimization.com css size

[Earl Miles]

Karoly Negyesi wrote:
> Let me sum up this topic, in form of a conversation:
> 
> -- We do not need drupal.css, let's move most of it to core themes.
> -- But then other themes need to theme admin which is pretty hard.
> -- Then let's make a separate admin theme.
> -- We do not really know what's admin and what's not.
> -- (Voice of Neil Drumm) What's under admin/ is admin.
> 
> That's my memory of this chat from all last year. We stopped here. 
> Let's  try to continue from here and not re-debate the former parts. I 
> know we  love debate. But there is a Drupal 4.7 which needs love. No, 
> you do not  need to code. It's enough if you review a patch a day. Not 
> more! If every  subscriber of this list would just do a good review  
> http://drupal.org/patch/review of just one patch each day then we would  
> have Drupal 4.7 by now.

Here's a semi-related idea.

Would we lose anything by creating a .CSS file dynamically? Instead of adding 
@import drupal.css/ @import theme/style.css; @import module/that.css

What if we did this:

First, as mentioned, break drupal.css up as said. There seems to be a lot of 
reason to do this.

Second, add a CSS registry. Not just a function to add it to the header, but 
instead, register every CSS file we want to give to the user. Themes could, if 
they like, tell the registry that they completely override any of the core 
Drupal files, or heck, even module files.

Third, when a request for drupal.css comes in, Drupal handles it. First, it 
looks in the cache. If it finds a cache, it sends it. It should skip as much of 
the Drupal load as possible in order to be as fast an efficient as we can make 
it; be very early in the Drupal run system.

Fourth, under the themes admin, we could put a list of all registered .css 
files, and checkboxes as to whether to include them. That way if a user modifies 
his or her theme to override global .css files that the theme didn't know about 
it, just check a box and that global .css theme is no longer included. It should 
also included a button to clear and/or disable the .CSS cache so that users 
doing development don't get screwed by it.

What problems does this address?

1) You can, if you like, get rid of drupal.css and anything it imports with the UI.
2) You eliminate having large numbers of .CSS files @imported. From the user 
perspective, there is just one.
3) Modifying this scheme could allow .JS libraries to be created and registered. 
I'll leave how that would work as an exercise for the reader, since I haven't 
thought it out at all.
4) It's very easy to break everything up into logical groupings.

What problems does this cause?

1) More resources used when getting the .CSS; I think this is only true if using 
the non-cached .CSS file. If the .CSS file is cached, this call should be caught 
very early, with the absolute minimum of code loaded.
2) A more complex scheme could offer more ways for the system to malfunction.
3) Someone would actually have to write the system.
4) Lag in cacheing could cause CSS changes not to appear until something 
invalidated the cache. I don't see this as a huge issue; with a toggle for 
development, that puts the onus on the developer for remembering to clear the 
cache. When modules or themes are saved, the cache can automatically be 
invalidated (and renewed!) right there.