[development] websiteoptimization.com css size

[Larry Garfield]

On Friday 06 January 2006 06:19 pm, Larry Garfield wrote:

> 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. :-)

It occurred to me after I sent this that it's dumb because whether or not to 
use a given module's CSS or JS file is not something that should be user 
configurable.  It should be theme-configurable only, otherwise the behavior 
could be unpredictable.  (MyTheme expects YourModule.css to not be active but 
it is, or expects it to be active but it isn't.)

So forget admin/modules.  Instead, a given theme can itself override a 
module's CSS/JS file by simply providing one of its own with the same name.  
So if mytheme wants to override yourmodule's default-provided CSS, it can do 
so by simply providing its own yourmodule.css file.  If it wants to just 
remove that styling completely and not provide its own version, just include 
an empty yourmodule.css file.  That could happen auto-magically or via a 
required callback function or declaration a la the way theme_* files are 
overridden.  

Alternatively, if people don't like magic names, modules could declare their 
css files via a very simple hook_styles() and JS via a simple hook_scripts(), 
both of which return a linear array of paths to the files they provide.  That 
would allow multiple files per module to allow a breakup into 
mymodule-structure.css and mymodule-appearance.css, for instance.  The theme 
override would be done the same way.  

In either case, the information would be cached per-theme and only rebuild 
when the module list or theme list changed.  We could probably cache the 
entire <style> and <script> strings pre-rendered and be done with it.

Thoughts?  Ber, would that take care of the "I don't want JS" issue you bring 
up?

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