[dojo-contributors] dojo.requireCss()?

James Burke jburke at dojotoolkit.org
Tue Jun 12 16:55:39 EDT 2007

On 6/12/07, Owen Williams <owen at smartsoul.com> wrote:
> On Jun 12, 2007, at 11:16 AM, James Burke wrote:
> > So to address the async loading issue with stylesheets as well as the
> > path abstraction, I'm wondering if we can support something like
> > dojo.requireCss(). It would resolve paths like dojo.require() does
> > today and also treat the CSS as a resource that needs to be loaded
> > before firing the domcontentloaded/onload callbacks. Example:
> >
> > dojo.requireCss("dijit.themes.dijit");
> >
> > which would map to dijit/themes/dijit.css. dojo.requireCss would pull
> > in the CSS contents, fix the css paths and inline the CSS via
> > something like the old insertCssText. It could process @import calls
> > to files that mapped to module-prefixed paths too.
> I think this is a great idea.
> I have been privately circulating a similar idea to make themes
> easier to load, more flexible, and able to be managed by the build
> system.  I'll send a separate proposal for that if folks think that
> requireCss() is a good idea.

Neato. I didn't mention it in the original email, but having the
dojo.requireCss() capability also means that we can do "inlining" of
the CSS into the built JS layer files, cutting down the number of
requests. We would not use that build option for official builds, but
for those people who want very custom builds, they could do it for

> > The icing on the cake: specifying an i18n bundle in a CSS comment that
> > should be loaded and allow token replacement with bundle values in the
> > CSS. This step could maybe be an optional add-on (since it depends on
> > i18n and string replacement code), but something I could have used
> > before.
> We do this sort of thing at Zimbra and it makes a lot of stuff
> possible in CSS that there is no other way to do.  James, I'd love to
> hear more about your thoughts on how this would work.

Maybe something like this would work, and it would not require any
special comments in the CSS file:

dojo.requireCss() can take a an array of strings or one string as a
second argument. Assume only one string is passed (the common case).
The string specifies a dojo module that will be allowed to process the
CSS before it is added to the document. dojo.requireCss() will do a
dojo.require for the module and track it as dependencies for the CSS
file. For example:

dojo.requireCss("my.main", "my.css.template");

requireCss will do a dojo.require("my.css.template"). my/main.css will
be passed through the my.css.template filter before the CSS is
attached to the DOM.

my.css.template would load the i18n bundle it wanted and define a
"filterCss" function. Example content for it:

dojo.requireLocalization("foo.bar", "bundleName"); //load the bundle
you are interested in.

my.css.template = {
    myBundle: dojo.i18n.getLocalization("foo.bar", "bundleName");
    filterCss: function(cssText){
        //Use this.myBundle and dojo.string.substitute() for token replacement.
        //Return the modified CSS.

If this seemed like a common operation, pull the above out as a common
module that other can extend, specifying just the i18n bundle that is
needed for the transform.

If you wanted to output both a french and english set of CSS rules
from this function, copy the input cssText, do one template replace
using english bundle, one with the french bundle then return the
combined css out of the filterCss function.

This sort of setup means that the dojo core is not bloated with
support for specific filters, it delegates via a dojo.require() to
load the things you need to do the template transform.


More information about the dojo-contributors mailing list