On Friday 06 January 2006 04:40 pm, Walt Daniels wrote:
One of the things websiteoptimization.com warns you about is too many objects on a page. Splitting the CSS file into many pieces will complain about that instead of the size of one of them. There is no free lunch.
Just because it complains doesn't mean the idea is automatically bad. :-) From a module developer perspective, though, I *want* to be able to provide my own module-specific CSS. Sure a theme author can do something else if he wants, but people should be able to get a functional and reasonably-well formatted module simply by dropping the module into the right directory and checking a checkbox. That means the module has to provide its own default CSS. I mentioned something a while back about moving more CSS to modules, but it was, I grant, a bit complicated. So what about this: We're talking about moving non-core modules out of /modules. Great, I agree, bring on /sites/all. That also then means that we can put core modules into their own subdirectories under /modules (or wherever core modules end up). Then, they can each have their own module-specific CSS files THERE. It means more files, but they're logically grouped by the module they relate to. To wit: /modules /aggregator /aggregator.module /aggregator.css /user /user.module /user.css /system /system.module /system.css ... Then, modules can either register their CSS file as appropriate (many contribs do this now), or the system could be "smart" and auto-include modulename.css on an enabled module and ignore it for disabled modules. No extra work from the module required. The result is more files, but each one is smaller and on repeated loads they're browser-cached anyway. Because few people have all core modules enabled, it will actually mean LESS CSS to send per user, on average, for a net bandwidth win, I'd wager. drupal.css goes away. Anything that doesn't fit to any specific module (eg, the various form element styles) goes to system.module. From a "I want to retheme it without having to untheme it first" perspective, it's at minimum no worse than the monolithic drupal.css. If the file is smart-loaded by name, actually, then it's probably a bit better, because it would be easier to add a feature to "don't load CSS from module X, but do load from module Y". That way it doesn't have to be an all-or-nothing matter. (Another column of checkboxes on admin/modules?) Now that I think of it, the same magic-name setup could work to breakup drupal.js per-module, and then the same mechanism could enable/disable js functionality per-module, too, for those who dislike all the new ajaxness in Core. (I agree it should be more optional than it is now.) OK, I think I started thinking aloud there. :-) To recap, I'm suggesting every module be required to be a directory in /modules (or wherever), and have magic-name files for resources as well as code. So any module consists of: /mymodule /mymodule.module (required) /mymodule.css (optional) /mymodule.js (optional) Then the admin/modules page gets 2 extra columns of checkboxes: Use Module CSS and Use Module JS, both of which default to on. The system then, based on those checkboxes, adds the appropriate <script> and <style> tags. Overall less code to send to the browser, more flexibility for themers, and more logical grouping of resources. I now await someone telling me why the above is dumb. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson