[development] websiteoptimization.com css size
merlin at logrus.com
Sat Jan 7 17:38:06 UTC 2006
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.
More information about the development