[wp-hackers] Adding A CSS Loader
omry at yadan.net
Tue Apr 24 12:23:29 GMT 2007
accessed via the admin interface.
everywhere, increasing overhead for the entire installation, some in
(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
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
>> 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 :-):
>> 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
>> 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
>> reduce the number of calls to the server to load X number of style
>> from each plugin that requires them.
> 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
> 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
>> 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
>> file for this to work, but if they don't then there is no problem, it
>> just fallback to the current method. Since the theme's CSS file will
>> 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
More information about the wp-hackers