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.