[development] websiteoptimization.com css size

[Larry Garfield]

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 at 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