[wp-hackers] Adding A CSS Loader

Tue Apr 24 12:23:29 GMT 2007

some plugins, like FireStats need to load their CSS/JavaScript only when 
accessed via the admin interface.
careless plugin authors just inject their plugins CSS/JavaScript 
everywhere, increasing overhead for the entire installation, some in 
many cases changing appearance and breaking javascript in other pages 
(its not rare that other plugins break FireStats operation by injexting 
crap into its admin page etc).
in FireStats, I do some tricks to avoid crapping the wrong page with 
CSS/JS 
(http://firestats.cc/browser/branches/firestats-1.2/firestats/firestats-wordpress.php#L222), 

but its a good idea to add some way for plugins to register CSS/JS hook 
just for their own pages more easily, or to check if the current page is 
their own more easily.

Sabin Iacob wrote:
> Jamie Holly wrote:
>> I just spent the weekend on a couple of sites I manage going through 
>> plugins
>> and stripping out all the CSS so it can all be contained within 1 file.
>> Considering the number of plugins using their own style rules, I was
>> thinking that perhaps we could take another lesson from something 
>> Drupal has
>> done recently and works great - A CSS loader.   
>
> glad to see that someone else shares my view :-): 
> http://wordpress.org/extend/ideas/topic.php?id=535&page&replies=2
>
>> Basically we would create a function, add_css('stylesheet_location'), or
>> something similar. This would store all the css files in an array which
>> would be dumped out with the proper format during the head call. What 
>> this
>> would also allow is for us to create a caching mechanism for all the CSS
>> files. Basically we could have Wordpress combine all the CSS files 
>> into a
>> master CSS file and then save that file in the cache directory. This 
>> would
>> reduce the number of calls to the server to load X number of style 
>> sheets
>> from each plugin that requires them.
>>   
>
> the current javascript loader is a better model; CSS files can also 
> depend on each other (the loading order is important).
>
> Combining the files, while it doesn't lower the server load*, it can 
> reduce load times a lot; if you have Firebug installed, load a page 
> that has several CSS and Javascript files and go to the net tab to see 
> what I mean: the stuff in the <head> section of the page is not 
> multi-threaded, they are loaded in sequence, and nothing else is 
> loaded before the <head> is done; lots of CSS and JS files to load 
> means lots of HTTP requests, and while pipelining in the browser can 
> help reduce the delays, you still get a lot of communication overhead.
>> We shouldn't have any legacy issues with this really, as those could 
>> still
>> require upon the head hook to inject their CSS (same applies to 
>> dynamic CSS
>> files). It would also require themes remove the CSS from their 
>> header.php
>> file for this to work, but if they don't then there is no problem, it 
>> will
>> just fallback to the current method. Since the theme's CSS file will 
>> also
>> remain stored with the theme, we can also continue to utilize the head
>> section of the CSS file for theme information.
>>   
>
> yeah, as long as the themes run wp_head after they load their stuff; 
> it wouldn't hurt to strongly advise theme (and plugin) authors to use 
> the provided loaders in the future (perhaps release them as a 
> (default) plugin for 2.0.x), since it would make life a lot easier for 
> plugin authors (some themes load prototype/jQuery/mootools/whatever, a 
> plugin shouldn't load the corresponding library a second time; plugin 
> CSS is usually better loaded after the theme CSS, but there may be 
> exceptions, etc).
>
> my .02€
>
> * as someone noted, you have a script call + a bunch of filesystem 
> hits; caching would reduce the filesystem accesses to two, but you 
> still have the script execution overhead
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers